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SECTION  1  -  INTRODUCTION 


This  report  describes  the  rationale,  methodology  and 
design  of  the  Circuit  Restoral  Assessment  Module  (CRAM) .  The 
CRAM  was  developed  in  order  to  assess  the  recoverability  of  the 
European  Defense  Communications  System  (DCS) .  In  previous 
studies  it  had  been  determined  that  the  European  DCS  System 
Control  capabilities  ware  vulnerable  to  the  nuclear  and  non-nuclear 
threat  and  that  system  connectivity  was  not  optimized  for  re¬ 
coverability.  These  studies  were  documented  in  a  CSC  report  to 
DMA  entitled, "Investigation  of  the  Vulnerability/Survivability 
of  Systems  Supporting  the  NCA  Decision  Process,"  2/76.  A  methodo¬ 
logy  for  quantitatively  assessing  the  recoverability  of  the  DCS  was 
subsequently  developed  and  documented  in  another  CSC  report  to  DNA 
entitled,  "Evaluation  of  Survivability/Recoverability  Aspects  of 
DCS  System  Control,"  12/77.  CSC  then  used  this  methodology  as  a 
basis  for  developing  an  automated  analysis  capability.  The 
resulting  tool  was  designated  the  CRAM. 

The  CRAM  performs  an  automated  analysis  of  the  recoverability 
of  the  European  Defense  Communications  System  (DCS) .  The  CRAM 
accomplishes  this  by  simulating  the  response  of  the  DCS  technical 
control  facilities  and  systems  control  elements  to  a  major  disrup¬ 
tion  in  the  DCS  telecommunications  network.  Given  a  scenario  in 
which  nodes  or  links  in  the  network  have  been  destroyed  or  otherwise 
disrupted,  the  module  identifies  disrupted  circuits,  establishes 
reroutes  for  those  circuits  for  which  reroute  paths  exist,  estimates 
circuit  restoral  times  based  on  reroute  path  length,  technical 
control  work  load,  technical  control  orderwire  availability  and 
systems  control  effectiveness,  and  produces  a  report  giving  the 
status  of  the  affected  circuits,  including  the  reason  for  disruption, 
the  reason  for  non-restoral  of  those  circuits  which  cannot  be 
restored,  and  the  estimated  restoral  time  of  those  circuits  which 
are  restored.  The  CRAM  is  designed  to  be  used  as  a  stand  alone 
module  or  as  a  component  module  of  an  Automated  Assessment  Tool  (AAT) 
developed  on  the  same  DNA  program. 


The  input  to  CRAM  is  a  threat  scenario  whir’,  may  include  any 
number  or  combination  of  disrupted  DCS  communications  links  or  nodes 
within  the  European  Theater.  CRAM  recognizes  two  states  in  the 
operational  status  of  a  link  or  node,  either  operational  or  non- 
operational.  CRAM  accepts  a  single  outage  time  and  this  time  is 
used  as  the  instant  of  degradation  and  the  time  at  which  restoral 
action  begins.  In  the  case  of  a  scenario  which  extends  over  a 
period  of  time,  an  instant  within  the  scenario  time  span  must  be 
selected  as  the  disruption  time  and  circuit  restoral  times  are 
estimated  as  if  all  damage  occurred  at  that  instant  of  time. 

Since  the  CRAM  data  base  presently  does  not  contain  the 
Pacific  Theater  and  CONUS,  the  first  step  in  circuit  restoral 
assessment  is  to  check  the  location  of  the  disrupted  link  or  node 
to  see  if  it  is  within  the  European  Theater.  If  it  isn't,  this 
fact  is  noted,  no  restoral  action  is  taken,  and  CRAM  looks  at  the 
next  disruption  in  the  scenario.  When  a  disrupted  station  or  link 
in  the  European  Theater  is  encountered,  CRAM  logs  out  all  the 
subsidiary  links,  routes,  trunks  and  circuits  normally  traversing 
the  disrupted  asset.  In  the  process  of  doing  this  it  also  identifies 
those  circuits  which  cannot  be  rerouted  due  to  a  disrupted  end 
terminal.  The  purpose  of  doing  this  is  to  avoid  searching  for 
reroute  paths  for  those  circuits. 

A  route  connectivity  matrix  is  used  for  finding  reroute  paths. 
This  matrix  contains  all  the  routes  which  can  be  used  for  rerouting 
purposes.  Therefore,  when  one  of  these  routes  is  disrupted  it  is 
no  longer  available  for  rerouting  purposes.  CRAM  removes  dis¬ 
rupted  routes  from  this  matrix. 

CRAM  establishes  the  existence  or  non-existence  of  orderwire 
connectivity  between  the  end  terminals  of  routes  that  are  to  be 
used  for  rerouting  circuits.  This  is  necessary  in  order  to  deter¬ 
mine  the  coordination  and  patching  times  when  estimating  circuit 
restoral  times.  If  ah  orderwire  which  directly  connects  the  end 
terminals  of  a  route  exists  and  is  operational,  then  coordination 
and  patching  time  over  that  route  is  shorter  than  if  direct 
orderwire  connectivity  does  not  exist. 
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Disrupted  circuits  and  groups  are  sorted  according  to  the  end 
points  of  the  disruption,  or  in  other  words,  according  to  the  two 
points  around  which  a  reroute  is  desired.  This  facilitates  restoral 
time  estimates  and  reduces  the  number  of  reroute  path  searches  in 
the  route  connectivity  matrix,  thus  reducing  computer  run  time. 

In  addition,  where  two  or  more  adjacent  routes  are  disrupted  in  a 
circuit  path,  the  adjacent  disruptions  are  concatenated  and  are 
treated  as  a  single  break  in  the  circuit.  This  allows  one  reroute 
path  to  be  established  around  multiple  disruptions. 

CRAM  then  finds  reroute  paths  for  the  disrupted  circuits. 
Because  of  the  heavy  channel  fill  in  the  DCS  and  the  large  number  of 
priority-one  circuits,  in  a  crisis  situation  in  which  extensive 
system  degradation  is  incurred,  the  only  circuits  that  would  be  re¬ 
routed  would  be  predominately,  if  not  all,  priority-one  circuits. 

For  this  reason,  and  to  simplify  the  restoral  algorithm  and  reduce 
computer  run  time,  CRAM  restores  only  priority-one  circuits. 

The  order  in  which  circuits  are  restored  and  the  manner  in 
which  reroute  paths  are  established  in  a  tech  control  facility  are 
simulated  by  the  CRAM  restoral  algorithm.  That  is,  highest  priority 
circuits  are  rerouted  first.  Reroute  paths  are  established  over  the 
shortest,  or  most  direct  paths  available.  In  general,  technical 
controllers  will  reroute  over  spare  channels  if  they  are  available, 
and  they  will  readily  preempt  non  priority-one  circuits  when  spare 
channels  are  not  available.  It  is  further  assumed  that,  tech 
controllers  will  not  preempt  lower  priority-one  circuits  with  higher 
priority-one  circuits  until  every  effort  has  been  made  to  locate 
spare  channels  or  non  priority-one  circuits  to  preempt.  All  the 
above  factors  have  been  included  in  the  restoral  algorithm  to 
realistically  simulate  technical  control  response  to  a  crisis 
situation. 

Having  established  reroute  paths,  CRAM  then  estimates  circuit 
restoral  times  based  upon  reroute  path  length,  tech  control  work¬ 
load,  orderwire  availability  and  systems  control  effectiveness. 
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Factors  affecting  circuit  restoral  times  which  could  not  be  taken 
into  account  such  as  tech  control  physical  layout,  insufficient 
patch  cords  and  interbay  trunks  for  extensive  rerouting, 
technical  controller  proficiency,  etc.,  will  probably  tend  to 
make  the  restoral  time  estimates  more  optimistic  than  what  would 
actually  occur.  Therefore,  restoral  time  estimates  made  by  CRAM 
should  be  considered  best  case  estimates. 

The  first  step  in  estimating  restoral  times  is  to  determine 
ACOC  effectiveness.  Again,  this  is  a  best  case  estimate  and  assume 
that  the  Area  Communications  Operations  Center  (ACOC)  can  fully 
assimilate  all  the  data  being  received  from  the  technical  control 
reporting  stations,  assess  the  data,  and  respond  quickly  with 
guidance  and  direction  to  the  affected  technical  control  facilities 
ACOC  effectiveness  is  estimated  by  CRAM  based  on  the  availability 
of  orderwires  or  other  communications  channels  between  the  ACOC  and 
the  technical  control  facilities.  These  communications  channels 
are  the  means  by  which  system  status  is  reported  to  the  ACOC,  and 
direction  and  guidance  is  provided  by  the  ACOC.  Without  this 
means  of  communications,  the  ACOC  would  be  fully  ineffective. 

CRAM  recognizes  three  states  of  effectiveness:  non-effective,  50 
percent  effective  and  100  percent  effective. 

CRAM  takes  into  account  reroute  path  length  when  estimating 
restoral  times,  reroute  path  length  being  the  number  of  routes 
that  must  be  interconnected  with  patch  cords  to  establish  the 
reroute  path.  The  more  patches  required,  the  greater  the 
coordination  and  patching  time. 

Coordination  and  patching  time  over  a  route  is  affected  by 
orderwire  availability  between  the  end  points  of  the  route.  If 
a  direct  orderwire  is  available  between  the  end  points,  then 
coordination  and  patching  time  is  a  minimum.  Where  a  direct 
orderwire  does  not  exist,  then  coordination  messages  must  be 
relayed  through  adjacent  technical  control  facilities,  over 
radio  maintenance  orderwires  or  via  AUTODIN  or  AUTOVON.  Thus, 


where  direct  orderwire  availability  does  not  exist,  longer 
coordination  time  estimates  are  used. 

Tech  control  work  load  is  accounted  for  by  using  elapsed 
time  logs  which  keep  crack  of  coordination  and  patching  time 
over  each  route  in  which  reroute  activity  is  taking  place.  It 
is  assumed  that  one  toch  controller  is  available  to  work  each 
end  of  a  route  and  that  no  more  than  one  tech  controller  at 
each  end  of  the  route  can  effectively  work  that  route.  Thus, 
multiple  reroutes  being  established  over  a  particular  route  are 
worked  sequentially  and  not  simultaneously. 

The  CCSD  records  are  updated  to  reflect  the  final  status 
of  each  circuit  and  an  output  report  is  produced  which  shows 
which  circuits  were  restored  and  their  restoral  times,  and 
which  circuits  could  not  be  restored  and  the  reason  for  non- 
res  toral. 

Section  2  of  this  report,  CRAM  Algorithm,  presents  a 
detailed  description,  the  algorithms  and  methodology  of  the 
CRAM.  Section  3  provides  a  description  of  the  CRAM  data  base  design, 
and  Section  4  provides  examples  of  analysis  of  scenarios  run  on 
the  CRAM. 


SECTION  2  -  CRAM  ALGORITHM 


The  following  paragraphs  provide  a  detailed  description  of  the 
CRAM  algorithms  and  methodology.  The  description  is  organized 
around  a  series  of  flow  charts  which  begins  witn  a  top  level  func¬ 
tional  flow  chart  and  then  goes  on  to  progressively  more  detailed 
flow  charts.  The  subroutine  flow  chart  identifiers  are  tabulated 
hierarchically  for  reference  in  Table  2-1. 

Within  the  flow  charts,  abbreviated  descriptions  are  provided 
within  each  symbol  of  the  process  performed.  Where  these  processes 
are  complex,  reference  is  made  to  subroutines  which  perform  the 
process.  Also,  associated  with  each  flow  chart  symbol  is  an  alpha¬ 
betic  character  which  facilitates  cross  reference  to  the  descriptive 
text. 

2 . 1  CRAM  Executive  Routine 

Figure  2-1,  CRAM  Executive  Routine,  presents  a  top  level  view 
of  the  CRAM  algorithm.  In  the  following  discussion,  the  alphabetic 
paragraph  numbers  correspond  to  the  alphabetic  characters  on  the  flow¬ 
chart  associated  with  each  flow  chart  symbol. 

(a)  The  scenario  is  read. 

( 3 )  All  the  disrupted  stations,  links,  routes,  trunks,  paths  and 

circuits  are  identified.  The  outage  time  is  entered  ir.  appro¬ 
priate  records.  Also,  routes  or  circuits  are  identified  which 
are  non-restorable  due  to  disrupted  end  terminals.  This  avoids 
going  through  a  reroute  path  search  for  non-restorable  circuits. 

(c)  Orderwire  connectivity  is  checked  and  orderwire  restoral 

times  are  logged.  Logging  orderwire  restoral  time  at  this 
point  is  justified  by  the  following  assumptions. 

1.  An  orderwire  will  logically  be  the  first  circuit  restored 
on  a  route. 

2.  The  reroute  path  will  be  one  route  long,  as  it  will  be 
restored  directly  on  the  route  that  it  supports. 
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Table  2-1.  CRAM  Subroutines 


1.0 

Identify  disruptions 

1.1 

Update 

Route  Connectivity 

1.1.1 

Update  Theater  Connectivity  Matrix 

1.2 

Set  CCSD  status 

1.2.1 

Log  multipoint  segments  out 

1.2.2 

Log  circuit  out  in  ACOC  Connectivity 

Matrix 

2.0 

Check 

orderwir 

e  connectivity 

3.0 

Sort 

circuits 

for  rerouting 

4.0 

Reroute  circuits 

4.1 

Path  search 

4.2 

Preempt 

non-priority  one  circuits 
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Figure  2-1.  CRAI1  Executive  Routine 
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3.  Restoral  time  will  be  nine  minutes  -  five  minutes  for 
local  damage  assessment  and  four  minutes  coordination 
and  patching  time. 

By  logging  orderwire  restoral  times  at  this  point,  one  avoids 
the  problem  of  an  iterative  routine  where  restoral  times 
are  established  for  all  the  circuits,  orderwire  restoral 
times  are  determined,  and  then  circuit  restoral  times 
are  recomputed  based  on  the  new  orderwire  connectivity. 

©  This  step  groups  all  the  circuits  together  that  must  be 

rerouted  between  any  two  particular  points.  This  accomplish¬ 
es  two  things.  First,  it  reduces  the  total  number  of  reroute 
path  searches  and  second  it  facilitates  circuit  restoral 
time  estimates  since  all  the  circuits  on  a  particular 
reroute  path  will  be  listed  together. 

(e)  Reroute  paths  are  searched  for. 

(f)  Restoral  times  on  rerouted  circuits  are  estimated. 

(g)  CCSD  records  are  updated  to  include  reroute  action  on 
circuits. 

©)  Output  reports  are  produced. 

2.2  Subroutine  1.0  -  Identify  Disruptions 

The  following  is  a  discription  of  Figure  2-2,  Subroutine  1.0  - 
Ider.cify  Disruptions. 

(a)  Those  stations  which  are  not  in  the  area  of  interest  can  be 
identified  by  the  DCA  area  code  and  (©  the  status  set  to 
3.  If  they  are  in  the  area  of  interest,  (©  the  status 
will  be  set  to  1,  disrupted  but  restorable.  The  status  code 
is  needed  in  the  restoral  algorithm  to  indicate  what  reroute 
action  is  appropriate  for  a  particular  route  or  circuit.  It 
can  also  be  used  in  the  output  report  to  indicate  why  the 
circuit  was  not  rerouted.  The  status  codes  are  as 
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Figure  2-2.  Subroutine  1.0  -  Identify  Disruptions 
(sheet  2  of  2) 
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follows: 


0  Operational 

1  Disrupted  but  restorable 

2  Not  restorable  due  to  disrupted  end  terminal 

3  No  reroute  attempted  because  not  in  area  of  study 

4  No  reroute  path  available 

5  TTY  circuit  -  no  reroute  action  at  DC  level 

6  Not  restorable  due  to  low  restoration  priority 

7  Circui4-  preempted  by  higher  priority  circuit 

(d)  This  step  determines  the  class  of  route,  identifies  the 
theater  and  updates  the  theater  connectivity  matrix. 

(e)  Setting  the  channel  number  to  XXX  serves  as  a  flag  to 
identify  a  disrupted  trunk (s)  when  looking  at  CCSD  connec¬ 
tivity. 

(f)  This  step  identifies  non-restorable  circuits  due  to 
status  2  and  6,  adds  restorable  circuits  to  the  disrupted 
circuit  list  and  updates  the  critical  control  circuit 
connectivity  matrix. 

2.3  Subroutine  1.1  -  Update  Route  Connectivity 

The  following  is  a  narrative  description  of  Figure  2.3. 

This  procedure  maintains  the  current  status  of  the  routes 
within  the  system  which  can  be  used  for  rerouting.  This  infor¬ 
mation  is  maintained  in  a  matrix  called  the  Route  Connectivity 
Matrix  (RCMX) .  As  routes  are  disrupted,  they  are  removed 
from  the  matrix. 

®  This  identifies  the  route  as  being  disrupted  but  potentially 
restorable. 

(b)  There  are  two  classes  of  routes.  The  route  class  is  a 

static  quantity  which  is  entered  manually  in  the  route  record 
when  the  data  base  if;  built.  A  class  "0"  route  is  one  for 
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which  no  possible  reroute  paths  exist.  Class  "O"  routes 
do  not  appear  in  the  route  connectivity  matrix.  Class  "1" 
routes  are  those  routes  for  which  at  least  one  possible 
reroute  path  exists.  If  it  is  a  Class  "0"  route,  no  action 
is  required. 

©  If  it  is  a  class  one  route,  the  theater (s)  in  which  the 
route  is  located  must  be  identified.  This  is  necessary 
because  each  theater  has  its  own  route  connectivity 
matrix. 

(d)  The  route  connectivity  matrix  is  updated  by  removing  this 
route . 

2.4  Subroutine  1.1.1  -  Update  Theater  Connectivity  Matrix 

Refer  to  Figure  2-4  in  following  this  discussion. 

The  route  connectivity  matrix  contains  all  the  routes  in  a 
particular  theater  which  can  be  used  for  rerouting  purposes  and 
is  used  for  finding  reroute  paths.  Each  time  one  of  these  routes 
is  di  pted,  it  must  be  removed  from  the  matrix,  as  it  is  no 
longe.  vailable  for  rerouting.  In  the  route  connectivity  matrix 
each  route  is  listed  twice,  once  for  each  end  terminal.  In  the 
route  master  file,  however,  each  route  is  only  listed  once.  The 
route  identifier  is  an  8  character  group  which  (1)  includes  the 
two  end  terminals,  (2)  the  theater  and  (3)  a  digit  which  identi¬ 
fies  a  particular  route  where  multiple  route  connectivity  exists 
between  two  points. 

EXAMPLE:  CLO  MRE  2  !. 

Uniquely  identifies  this 
-  Coltano  to  Mt.  Virgine  route 

i -  Identifies  the  theater 

-  Identifies  the  "to  node" 

! -  Identifies  the  "from  node" 
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A  convention  has  been  established  for  naming  the  routes  in  the 
route  master  file  in  that  the  two  end  terminals  are  listed 
alphabetically  in  the  route  identifier.  Thus  when  the  end 
terminals  of  the  route  are  known,  such  as  DON  and  CLO,  we  know 

that  the  route  identifier  will  be  CLODON _  and  not  DONCLO _ . 

In  the  route  connectivity  matrix  the  route  identifier  will  be 
listed  in  one  place  with  the  end  terminals  in  alphabetical 
order  and  in  another  place  with  the  end  terminals  in  reverse 
order.  For  example,  the  two  listings  for  the  CL0MRE21  route 
might  appear  as  follows: 


In  the  first  entry  the  record  key  is  the  from  node,  CLO.  In 
the  second  record  entry  the  record  key  is  the  to  node,  MRE. 

In  the  first  entry  the  route  identifier  can  be  constructed  by 
simply  concatenating  CLO  and  MRE21.  In  the  second  entry,  the 
route  identifier  cannot  be  constructed  by  simply  concatenating 
MRE  and  CL021  because  they  are  not  in  alphabetical  order. 

It  is  necessary  to  break  CL021  into  CLO  and  21  and  then  con¬ 
catenate  CLO,  MRE  and  21  to  get  CLOMRE21.  The  CL0MRE21  route 
example  will  be  used  in  the  following  flow  chart  description 
for  illustration  purposes. 

?T)  Find  the  "from  node"  key  in  the  matrix.  That  is,  find  the 
CLO  record. 

B)  Find  the  "to  node"  in  "from  node"  record.  That  is,  look 
for  MRE21  in  the  CLO  record. 

C)  Delete  "to  node"  from  "from  node"  record.  That  is,  delete 
MRE21. 
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Decrement  route  count.  Route  count  is  the  two  digit  number  i 

following  the  record  key.  It  specifies  the  number  of  routes 
represented  in  the  record.  Thus,  the  CLO  record  now  \ 

becomes: 


CLO 

m 

FEL  2  1 

DON  2  1 

HUM  2  1 

MRE  2  2 

(e)  Find  the  "to  node"  key  in  matrix.  That  is,  find  the  MRE 
record. 

©  Find  "from  node"  in  "to  node"  record.  The  "from  node"  will 
be  listed  in  the  record  as  "CL021".  Therefore  to  construct 
the  "from  node"  as  it  appears  in  the  record,  we  must  break 
CL0MRE21  into  CLO,  MRE  and  21  and  concatenate  CLO  and  21 
to  produce  CL021. 

©)  Delete  "from  node"  from  "to  node"  record.  (Same  as  C) . 

(©  Decrement  route  counter.  (Same  as  D) .  Thus  the  MRE 
record  becomes: 


MRE 

0  9 

CLO  2  2 

DON  2  1 

HUM  2  1 

NPS  2  1 

2.5  Subroutine  1.2  -  Set  CCSD  Status 

Refer  to  Figure  2-5  in  following  this  discussion. 

This  algorithm  determines  the  status  of  each  circuit  affected 
by  the  scenario.  All  circuits  with  status  1  require  reroute  action 
and  these  circuits  are  placed  in  a  disrupted  circuits  list  for 
future  use. 

(J)  If  the  multipoint  flag  is  not  equal  to  zero,  then,  it  is  a 
multipoint  circuit  and  requires  a  different  algorithm  ©) 
for  logging  it  out  and  setting  the  status. 
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©  If  it  is  a  CCC,  it  is  logged  out  in  the  ACOC  connectivity 
matrix  for  that  theater. 

If  it  is  not  a  VFCT  trunk,  no  further  action  is  required. 

If  it  is  a  VFCT,  the  trunk  must  be  logged.  This  is  the 
pseudo  trunk  corresponding  to  this  VFCT  circuit. 

Find  CCSD  master  and  log  CCSD  out. 

If  the  multipoint  flag  is  not  equal  to  zero,  then  the 
circuit  is  a  multipoint  circuit  and  a  separate  algorithm 
is  needed  to  handle  it. 

The  multipoint  segments  are  logged  out  individually. 

Status  5  is  used  on  DC  circuits  to  indicate  they  are 
out  and  reroute  action  is  not  being  taken  at  a  DC  level. 

If  it  is  a  CCC,  then  it  must  be  logged  out  in  ACOC 
connectivity  matrix  for  that  theater. 

Have  all  CCSDs  on  the  VFCT  been  logged? 

When  all  CCSDs  on  the  VFCT  have  been  logged  out,  control 
is  returned  to  the  calling  program. 

2.6  Subroutine  1.2.1  -  Log  Multipoint  Segments  Out 

Refer  to  Figure  2-6  in  following  this  discussion. 

Multipoint  circuits  are  logged  out  differently  than  point- 
to-point  circuits  in  that  the  path  connecting  each  combination 
of  two  users  is  treated  as  a  separate  circuit  when  user-to-user 
connectiv-ty  is  being  considered. 

©  Each  segment  (or  user  to  user  path)  is  identified  by  a 

unique  two  digit  number  where  the  first  two  characters  of 
the  CCSD  would  normally  be.  For  example,  if  DOOVWABC  were 
a  multipoint  orderwire  with  three  user  to  user  path 
combinations,  they  would  be  identified  as  010VWABC, 
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020VWABC  and  030VWABC.  The  multipoint  flag  in  the  parent 
CCSD  Master  record  contains  a  two  digit  number  which 
indicates  how  many  segments  there  are.  In  the  above  example, 
the  multipoint  flag  would  be  03.  To  get  from  the  segment 
CCS D  Master  back  to  the  parent  CCSD  Master,  the  multipoint 
flag  field  in  the  segment  CCSD  Masters  contain  the  first 
two  characters  of  the  CCSD.  Thus  the  multipoint  flags  in 
the  CCSD  Masters  for  010VWABC,  020VWABC  and  030VWABC  would 
each  contain  the  characters  "DO"  for  their  multipoint 
flags. 

©  If  the  eight  character  location  code  provided  by  the 

scenario  is  the  same  as  the  location  of  either  CCSD  end 
terminal,  it  is  assumed  that  the  end  terminal  has  been 
destroyed.  If  it  was  destroyed,  the  CCSD  segment  status 
is  ©  set  to  2. 

©)  If  the  segment  status  does  not  equal  zero,  the  segment 

is  already  logged  out  and  the  next  step  is  (j)  . 

(e)  Some  segments  of  a  multipoint  may  be  disrupted  whereas 

others  may  not.  The  only  way  to  determine  which  segments 
are  disrupted  is  to  examine  the  individual  CCSD  segment 
connectivities  and  see  if  they  are  routed  over  the  trunk 
that  is  presently  being  checked. 

If  the  segment  is  not  disrupted,  proceed  to  (j)  . 

If  the  circuit  is  one  of  the  TCF-ACOC  reporting  lines, 

then  it  is  (h)  logged  out  in  the  ACOC  connectivity  matrix. 

The  status  is  set  to  the  value  of  X  (from  Subroutine  1.0). 

After  all  segments  have  been  examined,  control  is  returned 
to  the  calling  program. 
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Subroutine  1.2.2  -  Log  Circuit  Out  in  ACOC  Connectivity 
Matrix 

Refer  to  Figure  2-7  in  following  this  discussion. 

The  ACOC  connectivity  matrix  is  made  up  of  one  large 
matrix  and  two  small  matrices  (or  records)  used  to  represent 
ACOC  connectivity.  The  large  matrix,  REPORTING  STATION 
CONNECTIVITY,  contains  all  the  circuits  that  can  be  used  by 
the  TCF  reporting  stations  to  communicate  with  the  ACOC.  These 
include  direct  connections  via  critical  control  circuits  (CCCs) 
and  indirect  connections  vi£.  the  AUTODIN  and  AUTOVON  networks. 

The  two  smaller  matrices  contain  circuits  connecting  the  ACOC 
to  the  networks.  There  are  thus  five  classes  of  circuits: 

1  Dedicated  CCCs  -  Reporting  station  to  ACOC 

2  AUTODIN  ACCESS  LINES  -  Reporting  station  to  AUTODIN 
network 

3  AUTOVON  ACCESS  LINES  -  Reporting  station  to  AUTOVON 
network 

4  AUTODIN  ACCESS  LINES  -  ACOC  to  AUTODIN  network 

5  AUTOVON  ACCESS  LINES  -  ACOC  to  AUTOVON  network 

This  subroutine  identifies  the  class  to  which  the  circuit  belorgs 
and  thus  identifies  the  proper  matrix  for  updating.  The  CCSD  is 
then  located  and  the  in  time  is  set  to  9999.  This  is  equivalent 
to  the  CCSD  being  out  for  the  duration  of  the  scenario. 

The  flow  chart  in  Figure  2-7  is  self  explanatory.  The  flag 
referred  to  in  the  decision  blocks  of  the  flow  chart  is  contained 
in  the  class  code  CKTMCLAS  element  of  the  circuit  Master  file. 

A  class  code  of  0  indicates  a  non-ACOC  circuit.  Class  codes 
1,  2,  3,  4  and  5  identify  CCC's. 

2.8  Subroutine  2.0  -  Check  Orderwire  Connectivity 

Refer  to  Figure  2-8  in  following  this  discussion. 

When  estimating  circuit  restoral  times,  it  is  necessary  to 
establish  the  existence  or  non-existence  of  orderwire 
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connectivity  between  the  end  terminals  of  a  route  in  order  to 
determine  coordination  and  patching  time.  If  there  is  an 
orderwire  directly  connecting  the  end  terminals  of  a  route,  and 
it  is  operational,  then  coordination  and  patching  times  over 
that  route  are  shorter  than  if  orderwire  connectivity  does  not 
exist. 

®  The  route  list  is  scanned  and  checked  for  orderwire 

connectivity  on  those  routes  which  are  class  1  (reroute 
paths  exist)  and  have  status  0  (operational) .  These 
are  the  routes  which  can  be  used  for  rerouting  purposes. 

©  Does  the  route  have  orderwire  connectivity  under  normal 
operating  conditions?  If  the  route  has  one  or  more  pre¬ 
engineered  orderwires  directly  connecting  the  end  terminal 
of  the  route,  then  orderwire  connectivity  status  is  set  to  1. 
The  two  conditions  of  orderwire  connectivity  status  are  as 
follows: 

0  Orderwire  connectivity  exists 
1  Orderwire  connectivity  does  not  exist 

If  the  route  normally  has  orderwire  connectivity,  then  it 
is  necessary  next  to  determine  if  at  least  one  orderwire  is 
operational. 

©)  The  status  of  an  orderwire  is  determined  by  refering  to 

the  CCSD  record  for  that  orderwire  and  checking  the  opera¬ 
tional  status.  (See  note  at  end  of  description) 

®)  If  the  orderwire  status  is  zero  (operational)  then  orderwire 
connectivity  exists  for  that  route  and  ©)  the  orderwire 
connectivity  status  in  the  route  record  is  set  to  zero. 

(F)  If  the  orderwire  status  is  not  zero,  it  mujst  be  determined 
if  it  is  1  (disrupted  but  restorable) . 
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(g)  If  the  status  is  1,  that  is  disrupted,  then  we  assume  that 
the  reroute  path  for  the  orderwire  will  be  over  the  route 
itself,  and  that  because  of  its  restoration  priority  (1A) 
it  will  be  the  first  circuit  restored  over  that  route-  The 
reroute  patching  and  coordination  time  for  the  orderwire 
is  logged  at  this  time.  The  patching  and  coordination  time 
begins  on  the  sixth  minute  following  the  disruption  and 
extends  through  the  ninth  minute.  The  first  five  minutes 
are  for  local  damage  assessment  and  will  be  logged  later. 

The  circuit  is  then  logged  in  on  the  CCSD  record  and  the 
connectivity  is  updated.  Additional  orderwires  for  that 
route  which  may  be  disrupted  will  be  rerouted  in  the  same 
manner  as  non-orderwire  circuits. 

(7)  If  all  orderwires  have  been  examined  and  their  status  is 

not  1  or  0,  they  are  non-restorable  and  orderwire  connecti¬ 
vity  does  not  exist  for  this  link.  Connectivity  status  is 
then  set  to  1. 

(j)  If  all  routes  have  been  examined,  control  is  returned  to 
the  calling  program. 

NOTE:  Many  orderwires  are  multipoint  circuits.  When  entering  the 
supporting  orderwires  in  the  CCSD  Master  Record,  the  unique 
orderwire  segment  CCSD  must  be  entered.  EXAMPLE: 

MULTIPOINT  CIRCUIT  DOOVWABC 
DON  RMN  FEL  ANU  SCH 

o — o 

FKT 

Users  are  DON,  FKT,  SCH. 
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Segments  are:  010VWABC  DON-SCH 

o - o - o - o - o 

DON  RMN  FEL  ANU  SCH 

020VWABC  DON-FKT 

o - o - o - o 

DON  RMN  FEL  FKT 

030VWABC  FKT-SCH 

o - o - o - o 

FKT  FEL  ANU  SCH 

Segments  are  identified  uniquely  by  replacing  the  first  two 
characters  of  the  CCSD  by  a  unique  two  digit  number. 

2.9  Subroutine  3.0  -  Sort  Circuits  for  Rerouting 

Referring  to  Figure  2-9,  this  algorithm  identifies  the  end 
points  of  reroute  paths,  identifies  the  circuits  to  be  rerouted 
over  each  reroute  path,  and  constructs  a  reroute  path  record 
(RPR)  for  each  reroute  path. 

(a)  The  theater  disrupted  circuits  list  is  called. 

(b)  A  CCSD  and  the  end  terminals  of  its  disruption  are  read 
from  the  disrupted  circuits  list. 

(c)  The  remainder  of  the  disrupted  circuits  list  is  scanned  for 
another  adjacent  disruption.  Two  disruptions  will  be  adjacent 

if  either  of  the  end  terminals  of  one  disruption  are  the  same  as 

either  of  the  end  terminals  of  another  disruption. 

EXAMPLE:  Adjacent  disruptions 

#1  #2 

DON-LKF  LKF-RSN  or  RSN-LKF 

Non-Ad jacent  Disruptions 
#1  #2 

DON-LKF  RSN-GAB 
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DISRUPTED 

CIRCUITS 

LIST 


Figure  2-9.  Subroutine  3.0  -  Sort  Circuits  for  Rerouting 
(sheet  1  of  2) 


^d)  &(f) If  there  are  adjacent  disruptions,  they  are  concatenated. 

EXAMPLE:  Prom  the  above  example  DON-LKF  and  RSN-LKP  when 

concatenated  become  DON-RSN 


This  is  necessary  because  adjacent  disruptions  are  consider¬ 
ed  a  single  disruption  for  rerouting  purposes.  At  this 
point  the  DON-LKF  and  RSN-LKF  entries  are  erased  from  the 
list,  since  they  have  been  accounted  for  in  the  concatena¬ 
tion  process.  It  is  then  necessary  to  scan  down  the  list 
again  to  see  if  there  might  be  additional  adjacent  disrup¬ 
tions.  It  is  also  necessary  to  check  for  multipoint  circuit 
hub  disruptions. 


EXAMPLE 


I 

O 

FKT 


Yields  DON-FEL,  FEL-SCH  and 
FKT-FEL  in  disrupted  circuit 
list. 


RPRs  must  be  generated  for  DON-SCH  and  DON-FKT,  making  DON 
the  new  hub. 

(f)  The  RPR  file  is  scanned  for  an  RPR  with  the  same  end 
terminals  as  the  disrupted  circuit. 

©&@If  an  RPR  exists  with  the  same  end  terminals  as  the 

disrupted  circuit,  then  this  circuit  is  added  to  the  RPR  if 
it  is  not  already  listed. 

©  «  an  existing  RPR  cannot  be  found  for  this  circuit,  one 

is  constructed. 

(j)  The  RPR  is  added  to  the  RPR  file. 

(k)  If  all  CCSDs  have  been  read  from  the  disrupted  circuits 
list,  then  (l)  the  disrupted  circuits  list  is  erased,  as 
all  the  information  is  in  the  RPRs  and  the  list  must  be 
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emptied  for  future  use. 

®  After  all  the  theaters  have  been  completed,  control  is 
returned  to  the  calling  program. 

I  10  Subroutine  4.0  -  Reroute  Circuits 

Referring  to  Figure  2-10,  this  algorithm  finds  a  reroute  path 
for  each  reroute  path  record  generated,  or  if  no  reroute  path  is 
available,  it  so  indicates.  Only  circuits  with  a  restoration 
priority  of  "1"  are  rerouted.  It  is  assumed  that  tech  controls 
will  reroute  over  spare  channels  if  they  are  available,  and  that 
they  will  readily  preempt  non  priority  one  circuits  when  spares 
are  not  available.  It  is  further  assumed  that  tech  controllers 
will  not  preempt  lower  priority-one  circuits  with  higher  priority- 
one  circuits  until  every  effort  has  been  made  to  locate  spare 
channels  or  non  priority-one  circuits.  The  first  half  of  the 
procedure  accomplishes  an  exhaustive  search  for  reroute  paths 
over  spare  channels  and  lower  priority  circuits.  If  a  reroute 
path  is  not  located  then  the  second  half  of  the  procedure  finds 
reroute  paths  by  preempting  lower  priority-one  circuits. 

®  The  Reroute  Path  Record  File  is  called. 

(IT)  Reroute  path  length  is  initialized  to  zero  in  order  to 
search  for  shortest  reroute. 

( C )  The  path  length  is  incremented.  The  "path  length"  specifies 

the  depth  to  which  a  reroute  path  search  will  be  conducted. 
That  is,  it  specifies  the  number  of  routes  in  a  reroute  path. 
The  algorithm  begins  by  looking  for  all  reroute  paths  of 
length  1.  It  then  searches  for  paths  of  length  2,  then  3, 
etc.,  up  to  some  maximum  length.  (Maximum  length  is  speci¬ 
fied  by  the  operator  and  will  normally  be  4  to  6).  This  is 
based  on  the  assumption  that  tech  controllers  will  reroute 
circuits  by  the  shortest  paths  available  first,  and  reroute 
longer  path  circuits  later. 
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Figure  2  10.  Subroutine  4,0  -  Reroute  Circuits  Csheet  2  of  5) 
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Figure  2  10.  Subroutine  4.0  -  Reroute  Circuits  (sheet  4  of 


Figure 2-10.  Subroutine  4.0  -  Reroute  Circuits  (sheet  5  of  5) 


Reroute  path  records  are  scanned  for  status  1.  That  is, 
disrupted  but  restorable.  Also  it  must  identify  reroute 
path  records  with  status  9.  Status  9  indicates  that  a 
path  search  has  already  been  accomplished  for  the  specified 
path  length  and  another  search  is  not  required  until  the 
path  length  is  incremented.  As  status  9  RPRs  are  genera¬ 
ted  they  are  added  to  the  bottom  of  the  list.  Thus,  the 
status  9  prevents  an  infinite  loop.  Therefore,  when  a 
status  9  is  encountered,  the  status  is  changed  to  1  (so 
it  will  be  caught  the  next  time  around  after  incrementing 
the  path  length)  and  the  next  record  in  the  list  is  examined. 

CCSDs  are  sorted  according  to  restoration  priority.  The 
CCSDs  and  restoration  priorities  are  moved  from  the 
reroute  path  record  and  placed  in  a  list  in  descending 
order  according  to  restoration  priority  with  the  highest 
priority  on  top.  This  insures  that  the  highest  priority 
circuits  will  be  rerouted  first. 

This  subroutine  performs  a  "next  neighbor"  search  for  a 
reroute  path  of  a  specified  length  between  the  two  end 
points  which  appear  on  the  reroute  path  record.  This  sub¬ 
routine  must  remember  wheth^'-  the  search  is  an  initial 
search  or  a  continued  search.  After  the  first  path  of  a 
specified  length  for  an  RPR  is  found  (initial  search)  the 
procedure  must  recall  where  it  stopped  so  that  it  can 
continue  on  later  to  look  for  additional  paths  of  the  same 
length  for  the  same  RPR  (continued  searches) .  This  conti¬ 
nues  until  all  the  reroute  paths  for  the  RPR,  at  the 
specified  length,  have  been  found,  or  all  the  CCSDs  on  that 
RPR  have  been  rerouted. 

Was  a  reroute  path  found? 


®  If  a  reroute  path  was  found,  it  must  be  determined  if  spare 
channels  exist  on  the  reroute  path.  This  is  determined  by 
checking  for  spare  channels  on  each  of  the  routes  on  the 
reroute  path.  The  number  of  spare  channels  available  is 
equal  to  the  number  on  the  route  with  the  fewest  spare 
channels. 

(T)  A  reroute  path  record  is  generated  and  the  reroute  path 
and  path  length  are  entered. 

(j)  CCSDs  and  RPs  are  moved  from  the  stack  to  the  reroute  path 
record  until  all  the  spare  channels  have  been  filled  or  until 
the  CCSD  stack  is  empty.  The  rerouted  circuits  are  added 

to  the  trunk/channel  on  which  they  were  rerouted  for  each 

route  in  the  reroute  path  and  the  channel  fill  for  each 

affected  trunk  and  route  is  updated.  The  channel  fill  that 

requires  updating  at  this  point  is  the  number  of  spare 

channels,  number  of  non-priority  one  circuits,  number  of 

priority  one  circuits,  highest  and  lowest  restoration  priority 

of  routes,  and  highest  and  lowest  restoration  priority  on 

affected  trunks.  * 

(k)  The  reroute  path  record  is  stacked.  It  is  necessary  to 
save  the  reroute  path  record  because  it  may  be  necessary  to 
come  back  to  it  and  later  preempt  non  priority -one 
circuits  on  that  path  if  all  the  CCSDs  cannot  be  rerouted 
over  spare  channels.  For  the  same  reason  it  is  necessary 

to  also  save  the  number  of  non  priority-one  circuits  on  i 

each  reroute  path  found.  ! 

( L )  Is  the  CCSD  stack  empty?  j 

I 

(m)  If  the  CCSD  stack  is  empty,  all  the  reroute  path  records 
are  unstacked  and  moved  to  the  reroute  path  record  file. 

Before  adding  them  to  the  file,  the  status  on  each  record 
is  set  to  zero,  which  indicates  that  reroute  action  has 
been  completed  on  those  records. 


If  the  CCSD  stack  is  not  empty  and  a  reroute  path  is  found 
which  does  not  have  spare  channels,  it  must  be  determined 
if  it  has  non  priority-one  circuits.  If  it  doesn't  have 
non  priority  one  circuits  it  is  discarded  and  (f)  a  search 
for  another  reroute  path  is  conducted.  If  it  does  have 
non  priority-one  circuits,  (o)  the  path  is  saved  by  genera¬ 
ting  a  reroute  path  record. 

The  path  is  saved  because  it  may  be  needed  if  there  aren't 
enough  spare  channels  to  reroute  all  the  CCSDs. 

If  this  was  not  a  continuing  search,  then  not  a  single 
reroute  path  was  found  between  the  two  points  in  question. 

If  it  was  a  continuing  search,  then  reroute  paths  were  found 
but  they  did  not  contain  enough  spare  channels  to  handle 
all  the  CCSDs. 

If  tne  reroute  path  record  stack  is  not  empty,  a  reroute  path 
record  and  its  channel  fill  (number  of  non  priority-one 
circuits)  are  removed  from  the  stack  to  facilitate  pre¬ 
emption  of  non  priority-one  circuits. 

Non  priority-one  circuits  are  preempted  until  the  supply  is 
exhausted  or  until  the  CCSD  stack  is  empty.  When  a  circuit 
is  preempted,  it  must  be  reflected  in  the  status  block  in 
the  CCSD  Master  record  and  the  connectivity  reassigned  to 
spare.  If  the  CCSD  status  is  not  already  set  to  2,  then  the 
status  is  changed  to  7.  If  the  status  is  2,  it's  already 
out  due  to  a  disrupted  end  terminal  and  the  status  should 
not  be  changed.  The  preempted  CCSD  and  restoration 
priority  in  the  Trunk  Master  records  of  the  reroute  path 
are  then  replaced  by  the  preempting  CCSD  and  restoration 
priority,  and  the  channel  file  is  updated.  The  preempting 
circuits  are  then  added  to  the  reroute  path  record. 
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0  The  reroute  path  record  i.  atus  is  set  to  0  and  the  record 
is  added  to  the  RPR  file. 

(t)  If  the  CCSD  stack  is  empty 

path  records  in  the  stack  are  erased.  If  the  stack  is  not 
empty,  then  (v)  the  reroute  path  record  stack  is  checked 
to  see  if  it  is  empty. 

(0  Is  the  reroute  path  record  stack  empty?  If  the  reroute 

path  record  stack  is  empty,  then  (0  a  reroute  path  record 
is  generated. 

(0  If  the  path  stack  is  empty,  the  remaining  CCSDs  in  the 

stack  are  added  to  the  reroute  path  record  just  generated, 
the  reroute  path  record  status  is  set  to  9  and  it  is  added 
to  the  reroute  path  record  file.  Recall  that  the  status 
was  set  to  9  so  that  when  this  reroute  path  record  is 
encountered  again,  another  reroute  path  search  is  not 
conducted  until  after  the  path  length  is  incremented.  When 
the  status  9  is  encountered,  the  status  is  changed  to  one 
so  that  action  may  be  taken  after  the  path  length  is  incre¬ 
mented. 


the  remaining  reroute 


If  the  entire  reroute  path  record  file  has  been  scanned, 
the  path  length  is  checked  to  see  if  it  has  reached  the 
maximum  allowable  value.  If  the  entire  file  has  not  been 
read,  (b)  the  next  record  is  read. 

If  the  maximum  path  length  has  been  reached,  then  the 
remaining  circuits  are  rerouted  by  preempting  lower  priority- 
one  circuits.  If  the  maximum  path  length  has  not  been  reached 
then  0)  the  path  length  is  incremented  and  the  search 
continues. 

If  a  reroute  path  was  not  found  (g)  and  it  was  not  a 
continued  search  0)  then  no  reroute  path  exists  at  the 
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current  path  length.  The  current  path  length  is  checked 

/''N 

to  see  if  it  is  the  maximum  allowed.  If  it  is  not,  then  tXj 

N - ^ 

the  reroute  path  records  are  checked. 

If  the  current  path  length  is  the  maximum  allowed,  then  no 
reroute  path  exists  between  the  two  end  points. 

The  reroute  path  record  status  is  set  to  4  (no  reroute 
path  available)  and  it  is  returned  to  the  reroute  path 
record  file. 

If  the  CCSD  stack  is  empty  then  no  other  CCSDs  have  to  be 
rerouted.  All  the  remaining  reroute  path  records  generated 
can  then  be  discarded. 

The  path  length  is  initialized  to  zero. 

Path  length  is  incremented  by  one. 

Reroute  path  records  are  scanned  for  a  status  1.  Again,  as 
status  9 ‘ s  are  encountered  they  are  changed  to  1 ' s  before 
proceeding  to  the  next  record. 

The  CCSDs  are  removed  from  the  reroute  path  record  and  placed 
in  the  CCSD  stack,  highest  priority  on  top. 

A  reroute  path  search  is  conducted.  As  above,  there  are 
initial  searches  and  continued  searches. 


If  a  path  was  found  uJ)  it  is  placed  in  the  path  stack.  Also 

the  restoration  priority  of  the  lowest  preemptable  on  the 

path  is  stacked  in  the  path  stack.  The  lowest  preemptable 

is  the  lowest  priority  on  that  route  which  has  the  highest 

low  priority.  For  example,  if  the  lowest  priorities  for  a 

five  route  path  are  as  follows 

ROUTE  1  R0UTE2  ROUTE  3  ROUTE  4  ROUTE  5 
1G  SPARE  1H  Non-one  IE 

The  lowest  priority  preemptable  circuit  on  this  reroute 

path  is  IE. 
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(LL)  The  priority  of  the  CCSD  at  the  top  of  the  CCSD  stack 

is  compared  to  the  priority  stored  with  each  path  in  the 
path  stack.  If  the  priority  in  the  path  stack  is  higher 
than  the  CCSD  priority,  this  path  cannot  be  used.  If  a 
path  with  a  lower  priority  is  found,  that  path  can  be  used 
to  reroute  a  circuit. 


If  there  is  a  path  that  can  be  used,  a  reroute  path  record 
is  generated  for  that  path  if  there  isn't  already  one.  The 
first  time  through  this  loop  the  reroute  path  record  that 
was  picked  up  in  step  (Fl)  is  used.  On  subsequent  passes 
through  the  loop  CCSDs  are  added  to  that  reroute  path 
record  for  additional  circuits  rerouted  over  that  path. 
However,  if  on  a  subsequent  pass  through  the  loop,  a 
reroute  is  established  over  a  different  path,  then  a  new 
reroute  path  record  roust  be  generated  for  that  path.  In 
the  following  example  the  priorities  in  a  CCSD  stack  are 
shown  in  descending  order,  and  the  priorities  in  three 
potential  reroute  paths  are  shown.  The  circled  numbers 
represent  the  order  in  which  the  CCSDs  in  the  CCSD  stack 
would  be  rerouted  and  the  same  number  appears  beside  the 
priority  that  would  be  preempted  in  the  path. 
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In  the  example,  path  #  1  is  the  first  one  encountered  with 
lower  priority  circuits  and  the  original  reroute  path  record 


would  be  used  for  that  path.  For  the  first  four  circuits, 
path  #1  would  have  the  lowest  priority  preemptable  channels. 
For  the  5th  circuit,  path  #3  would  be  the  only  path  with 
a  preemptable  channel.  For  the  last  circuit  in  the  CCSD 
stack,  none  of  the  paths  would  have  a  lower  priority 
channel  and  it  could  not  be  rerouted. 

A  CCSD  is  popped  from  the  stack  and  it  is  rerouted  over  the 
path  with  the  lowest  priority,  preempting  the  lowest  priority 
on  each  route  in  the  path.  After  each  such  preemption  it 
is  necessary  to  again  determine  what  is  the  lowest  priori ty 
channel  remaining  on  chat  path.  In  the  example,  after  the 
first  CCSD  was  rerouted,  the  lowest  priority  on  path  #1  was 
still  1H.  After  the  second  preemption  the  lowest  priority  was 
1G.  After  the  third,  it  was  IF.  And  after  the  fourth,  it 
was  1C. 

If  the  CCSD  stack  is  not  empty,  (Li)  another  preemptable 
channel  is  sought. 

If  the  CCSD  stack  is  empty,  the  status  is  set  to  0  on  all  the 
reroute  path  records  used  in  rerouting  these  circuits,  and 
the  reroute  path  records  are  moved  back  to  the  reroute  path 
record  file. 

If  all  the  records  have  not  been  scanned,  (F£)  the  next 
record  is  examined. 

If  they  have,  then  it  is  determined  if  the  maximum  path 
length  has  been  reached.  If  it  has,  control  is  returned  to 
the  calling  program.  If  it  hasn't,  go  back  to  (EE!)  . 

If  a  reroute  path  was  never  found,  the  CCSDs  are  moved  from 
the  stack  back  to  the  reroute  path  record. 

If  there  aren't  any  more  preemptable  channels,  the  reroute 
path  record  status  is  set  to  0  on  any  paths  on  which  circuits 
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were  rerouted  and  return  these  reroute  path  records  to  the 
file.  Note  that  it  may  not  have  been  possible  to  reroute 
any  of  the  CCSDs  in  which  case  there  won't  be  any  reroute 
path  records  to  return  to  the  file. 


Any  circuits  remaining  in  the  CCSD  stack  must  be  put  on  a 
reroute  path  record  for  eventual  return  to  the  file.  If  no 
CCSDs  were  rerouted  the  same  reroute  path  record  started 
with  at  (et)  can  be  used.  However,  if  this  reroute  path 
record  has  already  been  used,  a  new  one  must  be  generated. 


(ww)  It  is  determined  if  the  path  length  is  the  maximum  allowed. 

(XX)  If  it  is,  the  status  of  the  reroute  path  record  is  set  to  4 

(no  reroute  path  available) . 


(yy)  If  it  isn't,  the  status  is  set  to  9. 

(zz)  The  reroute  path  record  is  added  to  the  file. 


2.11  Subroutine  4.1  -  Path  Search 


Referring  to  Figure  2-11,  this  subroutine  performs  the  actual 
reroute  path  search.  There  are  two  types  of  search,  an  initial 
search  and  a  continuing  search.  Referring  to  the  calling  program, 
subroutine  4.0,  the  initial  search  is  the  first  search  conducted 
for  a  particular  RPR.  After  a  reroute  path  is  found,  it  is  out¬ 
putted  to  the  calling  program  and  then  a  new  search  for  additional 
paths  is  conducted  where  the  old  search  left  off.  This  procedure 
is  repeated  until  all  paths  at  a  particular  path  length  between  two 
points  have  been  found. 

(a)  If  this  is  a  continued  search,  the  top  FMNODE  and  TONODE 

are  popped  from  the  stack  and  the  process  continues  it  (n) . 

On  the  initial  search  the  stack  is  cleared  of  any  residue. 

Depths— 1.  The  depth  is  an  indicator  of  the  current  depth 
of  the  search.  That  is,  how  many  routes  deep,  from  the 
FM-END,  has  the  search  progressed. 
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Qd)  The  FM-END  and  TO_END  are  the  disruption  end  points.  These 
are  the  two  points  between  which  a  reroute  path  must  be 
found. 

(e)  FMNODE  =  FM-END.  The  FMNODE  (from  node'  is  the  node  from 
which  the  program  is  currently  looking.  The  first  FMNODE 
naturally  will  be  the  starting  point,  the  FM-END. 

( F )  The  FMNODE  record  is  found  in  the  Route  Connectivity  Matrix 

( RCMX ) . 

(g)  A  TONODE  is  read  from  the  FMNODE  RCMX  record. 

(h)  If  the  TONODE  is  equal  to  the  TO_END ,  a  reroute  path  has 

been  found  and  the  program  proceeds  to  (s)  . 

©  It  is  necessary  to  check  if  the  TONODE  is  any  FMNODE  in 

the  stack  in  order  to  avoid  searching  in  a  circle.  If  the 
TONODE  is  already  in  the  stack  as  a  FMNODE,  then  (n)  the 
algorithm  proceeds  to  look  at  the  next  TONODE  on  the  FMNODE 
RCMX  record. 

(j)  The  desired  path  length  is  that  path  length  determined  in 

the  calling  progra.;.,  subroutine  4.0.  If  the  depth  is  equal 
to  the  path  length  then  it  doesn't  search  any  deeper,  but 
proceeds  to  (©  and  looks  at  the  next  TONODE  on  the  record. 

(k)  The  FMNODE  and  TONODE  are  stacked,  as  the  desired  path 

length  has  not  been  reached  and  it  is  necessary  to  look  one 

route  deeper. 

(©  The  old  TONODE  is  used  as  the  new  FMNODE. 

(m)  The  depth  is  incremented. 

(n)  If  all  TONODES  in  the  record  have  not  been  read,  proceed  to 
©)  and  read  the  next  one. 

©)  If  the  stack  is  empty,  the  search  has  been  exhausted,  and 
control  is  returned  to  the  calling  program. 
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FMNODE  and  TONODE  are  popped  from  the  stack  and  the  search 
continues  from  the  next  TONODE  on  the  previous  FMNODE  record. 
NOTE:  It  not  only  pops,  but  it  must  erase  the  FMNODE  and 

TONODE  from  the  stack  since  they  must  not  be  present  in 
Step  (T)  . 

The  depth  is  decremented. 

After  having  found  a  path  in  (©  ,  it  now  must  be  determined 
if  the  path  is  the  proper  length.  For  example,  there  may  be 
four  route  paths  which  cannot  be  used  because  they  contain  all 
high  priority  circuits.  When  a  subsequent  search  for  five 
route  paths  is  conducted  the  four  route  paths  will  be  encoun¬ 
tered  again,  but  they  must  be  ignored,  since  it  has  already 
been  determined  that  they  cannot  be  used.  If  it  is  not  the 
desired  length,  the  program  proceeds  to  ©)  and  looks  at  the 
next  TONODE. 


©  If  a  path  of  the  desired  length  has  been  found,  then  the 
present  FMNODE  an^  TONODE  are  stacked  so  that  the  entire 
reroute  path  is  loaded  in  the  stack. 

©  Route  names  are  constructed  from  FMNODE s  and  TONODEs  in  the 

stack.  The  subroutine  1.1.1  description  contains  a  discussion 
on  route  name  construction. 

NOTE:  The  contents  of  the  stack  are  not  disturbed,  but 

the  route  names  are  loaded  into  a  buffer  and  outputted 
to  the  calling  program. 


2.12  Subroutine  4.2  -  Preempt  Non  Priority-One  Circuits 

Referring  to  Figure  2-12,  this  procedure  preempts  non  priority- 
one  circuits,  and  for  the  circuit  being  rerouted,  it  updates 
the  connectivity  by  removing  the  disrupted  trunk/channel  and 
entering  in  its  place  the  trunk/channels  of  the  reroute 
path. 
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Figure  2-12.  Subroutine  4.2 
(sheet  1  of  4) 


Preempt  Non 
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Figure  2-12.  Subroutine  4.2 
(sheet  3  of  4) 


-  Preempt  Non  Priority-One  Circuits 


Figure  2-12.  Subroutine  4.2  -  Preempt  Non  Priority-One  Circuits 
(sheet  4  of  4) 


A  routs  designator  is  read  from  the  RPR.  This  is  one  of 
the  routes  of  the  reroute  path. 

This  route  master  record  is  read. 

The  lowest  restoration  priority  field  (RTEMLORP)  is  read. 

This  provides  the  value  of  lowest  restoration  priority  on 
the  route. 

A  subsidiary  trunk  master  is  read. 

The  lowest  restoration  priority  field  (TRKMLORP)  is  read. 

This  provides  the  value  of  the  lowest  restoration  priority 
on  the  trunk. 

TRKMLORP  =  RTEMLORP?  The  lowest  priority  on  the  route  must 
equal  the  lowest  priority  on  at  least  one  of  its  trunks.  A 
search  is  conducted  until  the  first  such  trunk  is  found. 

After  having  found  the  trunk,  it  is  necessary  to  search  for 
the  circuit  with  that  priority. 

The  CCSD  restoration  priority  is  read- 

CKTMREST  =  TRKMLORP?  In  other  words,  is  this  the  CCSD  with 
the  lowest  priority.  NOTE:  There  may  be  more  than  one.  The 
first  one  found  will  suffice. 

Is  this  a  multicircuit  channel?  Some  VF  channels  will 
carry  more  than  one  data  circuit  or  several  time  sharing  VF 
circuit.  If  this  channel  is  to  be  preempted,  all  the  circuits 
on  it  will  be  preempted.  If  it  is  a  multi-circuit  channel, 
the  program  proceeds  to  (n)  . 


The  CCSD  status  is  set  to  7.  If  this  isn't  a  multicircuit 
channel,  then  it  is  immediately  preempted.  When  a  circuit 
is  preempted  the  status  is  set  to  7  in  the  CCSD  master. 

Erase  the  CCSD  from  CKRV  file.  Since  the  circuit  is  preempted, 
its  connectivity  is  no  longer  of  any  concern. 
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(m)  The  trunk  and  channel  are  stacked  so  that  the  connectivity 
of  the  circuit  being  rerouted  can  be  updated  after  all  the 
trunk/channels  on  the  reroute  path  have  been  found. 

©  If  the  channel  was  a  multicircuit  channel,  the  other 

circuits  on  it  must  be  checked  to  make  sure  none  of  rhem 
are  of  a  higher  priority  than  that  which  is  to  preempt-  it. 

©  The  CCSD  Master  is  read. 

(?)  CKTMREST  =  TRKMLORP .  In  other  words,  is  the  restoration 
priority  of  all  the  circuit (s)  on  the  channel  equal  to  or 
lower  than  the  preempting  priority.  If  not,  then  this 
was  not  the  channel  being  sought,  and  the  program  goes  back 
to  ©)  and  looks  at  the  next  one. 

(q)  If  all  circuits  on  the  channel  have  been  checked  and  it 

is  found  that  all  are  equal  to  or  lower  than  the  preempting 
priority,  then  the  channel  can  be  preempted. 

®@©  &©}  All  those  circuits  are  removed  from  the  trunk 
and  the  CCSD  Master  status  is  set  to  7,  preempted. 

(?)  The  trunk  channel  is  stacked. 

(w)  The  channel  fill  on  the  routes  and  the  trunk  are  updated. 

(x)  After  the  trunk-channels  have  been  found  on  each  route,  the 
program  proceeds  to  update  the  connectivity  of  the  rerouted 
circuit. 

©  The  rerouted  CCSD  connectivity  is  searched  for  the  break  point 
The  disrupted  trunk/channels  are  identified  by  the  characters 
XXX  where  the  channel  number  should  be. 

©)  The  disrupted  trunk (s)  are  removed  from  the  connectivity 
and  the  reroute  path  trunk-channels  are  inserted  from  the 
stack. 
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2.13  Subroutine  4.3  -  Preempt  Spares 

Referring  to  Figure  2-13,  this  procedure  preempts  spare  channels, 
and  for  the  circuit  being  rerouted,  it  updates  the  connectivity 
by  removing  the  disrupted  trunk/channel  and  entering  in  its 
place  the  trunk/channels  of  the  reroute  path. 

©  This  check  is  necessary  to  determine  when  all  the  spares  on 
the  reroute  path  have  been  used  up. 

2)  Preempting  CCSD  is  read  from  CCSD  stack. 

2)  A  route  designator  is  read  from  the  RPR. 

2)  The  route  master  record  is  read. 

2)  A  subsidiary  trunk  master  record  is  read. 

2)  "Lowest  priority"  field  (TRKMLORP)  is  read.  Spare  channels 

will  be  assigned  a  restoration  priority  such  as  "SP"  or  "SA". 

©  If  the  lowest  priority  is  spare,  then  a  trunk  has  been 
found  that  can  be  used. 

The  spare  CCSD  is  erased  from  the  'JKRV  file. 

©  All  the  trunk  channels  used  for  rerouting  are  saved  so  that 
in  (m)  they  can  be  used  to  update  the  connectivity  of  the 
circuit  being  rerouted. 

©  Have  all  routes  on  RPR  been  done?  In  other  words,  has  the 
rerouted  circuit  been  put  on  all  the  routes  ir.  the  reroute 
path? 

©  Trunk  and  route  channel  fill  are  updated.  The  number  of 

spare  channels  on  the  trunk  and  route  have  to  be  reduced  by 
one,  the  highest  or  lowest  priority  changed,  if  necessary, 
and  the  number  of  one  priority  circuits  incremented  by  one. 

2)  Rerouted  CCSD  connectivity  is  searched  for  disruption  point. 

That  is,  disruption  that  is  being  rerouting  around  is 
located  in  the  connectivity. 
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(^M)  CCSD  connectivity  is  updated  with  trunk-channels  in  stack. 

In  other  v?ords,  the  disrupted  connectivity  is  replaced 
with  the  reroute  path. 

®  If  the  CCSD  stack  is  empty,  control  is  returned  to  the 
calling  program. 

2.14  Subroutine  5.0  -  Estimate  Restoral  Times 

Referring  to  Figure  2-14,  this  procedure  computes  an 
estimated  restoral  time  for  each  circuit  rerouted.  This  estimate 
is  based  on  ACOC  effectiveness,  reroute  path  length,  technical 
control  orderwire  connectivity  and  technical  control  workload. 

(a)  A  theater  is  selected.  This  procedure  is  performed  on  one 
theater  at  a  time,  since  each  theater  has  its  own  ACOC 
effectiveness,  connectivity  matrix  and  RPR  file. 

(5)  ACOC  effectiveness  is  computed. 

(c)  Circuit  restoral  times  are  assigned. 

®  After  all  theaters  have  been  completed,  control  is  returned  to 
to  the  calling  program. 

^.15  Subroutine  5.1  -  Determine  ACOC  Effectiveness 

Referring  to  Figure  2-15,  this  procedure  is  used  to  estimate 
the  effectiveness  of  the  ACOC  in  providing  assistance  to  the 
technical  control  facilities  which  are  involved  in  reroute  activity 

(a)  Station  work  status  is  checked.  This  procedure  is  used  to 
determine  which  tech  control  facilities  are  involved  in 
reroute  activity. 

(b)  Working  station  reporting  status  is  determined.  This 
procedure  determines  whether  communications  circuits  exist 
between  the  TCF  reporting  stations  and  the  ACOC.  These 
circuits  are  used  to  report  status  to  the  ACOC  and  receive 
direction  from  the  ACOC.  The  availability  of  such  circuits 
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determines  the  effectiveness  of  the  ACOC  in  performing 
its  function. 

(©  ACOC  effectiveness  is  computed.  There  are  three  levels 
oi  ACOC  effectiveness,  0%,  50%  and  100%.  The  level  of 
ACOC  effectiveness  is  a  factor  considered  when  estimating 
restoral  times. 

2.16  Subroutine  5.1.1  -  Check  Station  Work  Status 

Refers c.g  to  Figure  2-16,  this  procedure  determines  which 
stations  are  involved  in  reroute  activity.  This  information  is 
necessary  to  compute  ACOC  effectiveness  since,  in  general,  only 
those  stations  which  are  rerouting  are  interacting  with  the 
ACOC.  Thi'.  is  accomplished  by  examining  the  end  station  on  the 
reroute  path  records  (RPRs)  and  compiling  a  list  of  these 
stations.  The  TCF  reporting  stations  are  then  checked  to  see  if 
they  appear  on  the  list:. 

The  RPR  file  is  called. 

An  RPR  record  is  read. 

The  first  disruption  end  point  is  read. 

The  list  of  stations  thus  far  compiled  is  checked  to 
see  if  the  station  is  already  listed.  This  list  of 
stations  is  called  tne  "working  station  list". 

The  station  is  added  to  the  working  station  list. 

The  second  disruption  end  point  is  read. 

&  (h)  Same  as  D  &  E 

If  all  RPRs  have  been  checked,  (j)  the  RPR  file  is  returned. 

REPORTING  STATION  CONNECTIVITY  Matrix  is  called. 

A  station  name  is  read  from  matrix.  The  station  name  is  the 
key  for  each  record  in  the  matrix. 


Figure  2  -16.  Subroutine  5,1,1  -  Check  Station  Work  Status 
(sheet  2  of  2) 


(m)  Is  name  in  working  station  list?  If  the  station  name  is  in 
the  working  station  list,  then  (o)  the  station  work  status 
is  set  to  1.  If  it  isn't  then  (®  the  station  work  status 
is  set  to  0. 

(p)  After  all  the  records  in  the  matrix  have  been  read, 
control  is  returned  to  the  calling  program. 

2.17  Subroutine  5.1.2  -  Determine  Station  Reporting  Status 

Referring  to  Figure  2-17,  the  purpose  of  this  procedure  is  to 

determine  which  working  stations  have  connectivity  with  the 

ACOC  when  reroute  activity  is  being  performed. 

®  The  ACOC-AUTODIN  connectivity  record  is  read.  This  record 
lists  all  the  ACOC  AUTODIN  access  lines  and  thus  reflects 
the  ability  of  the  ACOC  to  access  the  AUTODIN  network. 

®  DCON  is  an  acronym  for  AUTODIN  connectivity  time.  That  is, 
the  time  at  which  the  ACOC  has  connectivity  with  the 
AUTODIN  network.  This  time  is  initialized  to  9999.  In 
other  words,  9999  indicates  that  at  this  time  it  is  assumed 
that  connectivity  will  not  exist  until  the  scenario  is  over. 

©  CCSD  in  time  is  read.  That  is,  the  in  time  for  the  first 

CCSD  in  the  record  is  read. 

(5)  In  time  <  DCON?  If  in  time  for  the  CCSD  is  not  less  than 
the  DCON  time,  then  (©  the  next  CCSD  in  time  is  read  if 
©)all  the  in  times  have  not  been  checked.  What  this 
does  is  pick  the  earliest  time  at  which  ACOC-AUTODIN  connecti¬ 
vity  existed. 

(©  ,  DCON-*-In  Time.  If  the  CCSD  in  time  is  less  than  the  DCON 

time,  then  the  CCSD  in  time  becomes  the  new  DCON  time. 

(F)  Have  all  in  times  been  checked?  If  all  the  AUTODIN  CCSD 

in  times  have  been  checked  then  the  same  thing  is  done  for 
the  AUTOVON  access  lines. 
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An  ACOC-AUTOVON  CONNECTIVITY  record  is  read. 

VCON-*— 9999.  VCON  is  an  acronym  for  AUTOVON  CONNECTIVITY. 

It  is  initialized  to  9999. 

Read  CCSD  in  time.  Same  as  (?) 

In  Time  < VCON.  Same  as(?) 

VCON-*—  IN  Time.  Same  as(i) 

Have  all  in  time  been  checked?  Same  as(?) 

The  records  in  REPORTING  STATION  CONNECTIVITY  matrix  are 
scanned  to  identify  those  reporting  stations  which  are 
involved  in  reroute  activity. 

If  the  work  status  is  not  equal  to  1,  then  it  doesn't 
matter  if  the  station  has  connectivity  or  not,  since  it  will 
not  be  counted  when  computing  ACOC  effectiveness. 

RCON-* — 9999.  RCON  is  an  acronym  for  report ina  station 
connectivity  time.  It  is  initialized  to  9999. 

A  CCC  in  time  is  read. 

In  TIME  <  RCON.  If  the  in  time  is  not  less  than  the  RCON, 

the  program  (?)  takes  a  look  at  the  next  in  time. 

(r)  RCON-* — In  time.  If  the  in  time  is  less  than  the  RCON  time, 

then  the  in  time  becomes  the  new  RCON.  This  establishes  the 
earliest  time  at  which  CCC  connectivity  exists  between 
the  TCF  and  ACOC. 

(?)  If  all  the  CCC  in  times  have  been  checked,  then  the  program 
goes  on  to  check  the  connectivity  via  the  AUTODIN  network. 

(t)  AUTODIN  ACCESS  LINE  in  time  is  read.  This  would  be  the  in 
time  for  one  of  the  AUTODIN  access  lines  in  the  second 
section  of  the  REPORTING  STATION  CONNECTIVITY  matrix. 
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If  the  in  time  was  less 


In  Time  <  DCON. 


than  the  DCON  time, 


then  DCON  time  is  used  since  both  the  TCF  and  the  ACOC  need 
connectivity  to  the  AUTODIN  Network  before  it  can  be  used 
for  communicating.  The  program  thus  proceeds  to  (x)  . 

In  Time  <  RCON. 

In  Time-* — RCON.  If  the  in  time  is  less  than  the  RCON  time 
then  the  in  time  becomes  in  the  new  RCON  time. 

DCON  <  RCON. 

DCON-* — RCON.  If  the  DCON  is  less  than  the  RCON  time,  then 
the  DCON  time  becomes  the  new  RCON  time. 

If  all  AUTOVON  access  line  in  times  have  been  checked  then 
the  next  step  is  to  check  the  connectivity  via  the  AUTOVON 
network. 


These  blocks  perform  the  same  checks  on  AUTOVON  lines  as 
the  corresponding  blocks  in  (?)  through  (z)  do  for  the 
AUTODIN  lines. 

(Hi)  If  every  working  station  has  been  checked,  then  control 
is  returned  to  the  calling  program. 

2.18  Subroutine  5.1.3  -  Compute  Effectiveness 

Referring  to  Figure  2-18,  after  the  working  stations  have  been 
identified  and  the  connectivity  status  of  these  stations  deter¬ 
mined,  this  procedure  calculates  the  actual  ACOC  effectiveness. 
The  ACOC  effectiveness  is  a  function  of  TCF-ACOC  connectivity. 

For  connectivity  0<o  -3%,  ACOC  effectiveness  is  considered  to  be 
0%.  For  TCF-ACOC  connectivity  25sCs75%,  ACOC  effectiveness  is 
50%,  and  for  TCF-ACOC  connectivity  75<C<100%,  ACOC  effectiveness 
is  considered  to  be  100%. 

(a)  STCOUNT  and  RECOUNT  are  acronyms  for  working  stations  count 
and  reporting  line  count.  These  counters  keep  track  of  the 
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Figure  2-18.  Subroutine  5.1.3  -  Compute  Effectivene; 
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total  number  of  TCP's  involved  in  reroute  activity  (STCOUNT) 
and  the  number  of  these  TCP's  (RLCOUNT)  which  can  communicate 
with  the  ACOC.  The  counters  are  initialized  to  zero. 

A  station  record  in  the  reporting  station  connectivity  matix 
is  read. 

If  the  work  status  is  not  equal  to  1,  then  this  station  is 
not  counted. 

The  count  of  working  stations  is  incremented. 

Is  RCON  time  k  hit  time. 

If  RCON  is  not  equal  to  or  less  than  the  time  of  the  next  dis¬ 
ruption  then  this  station  cannot  communicate  with  the  ACOC. 

The  count  of  TCF's  which  have  ACOC  connectivity  is  incremented. 

Have  all  stations  been  checked. 

Percent  —  RLCOUNT/STCOUNT 

Percent  is  the  fraction  of  working  TCF’s  which  have  ACOC 
connectivity. 
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^M)  Self  explanatory. 

2.19  Subroutine  5.2  -  Assign  Restoral  Times 

Referring  to  Figure  2-19,  after  all  reroute  paths  have  been 
found  and  stored  in  the  reroute  path  records,  this  procedure  compu¬ 
tes  restoration  times  for  each  circuit.  In  order  to  do  this,  it 
is  necessary  to  keep  track  of  reroute  activity  time  in  each  tech 
control  facility.  To  accomplish  this,  it  is  assumed  that  a 
tech  controller  is  available  at  each  end  of  a  route  and  can  devote 
full  time  attention  to  that  route.  Each  tech  controller’s  time  is 
then  accounted  for  in  the  working  time  logs  in  the  route  master 
record.  There  are  two  such  logs  in  each  route  master.  One  for 
the  tech  controllers  at  each  end  of  the  route.  The  first  log 
is  for  the  controller  at  the  first  end  and  the  second  is  for 
the  controller  at  the  second  end. 
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Figure  2-19.  Subroutine  5.2  -  Assign  Restoral  Times  (sheet  3  o 


The  theater  reroute  path  record  (RPR)  file  is  read. 

The  RPRs  are  scanned  for  those  with  status  =  0. 

The  number  of  routes  on  the  RPR  is  read.  This  number  is 
entered  in  the  record  when  the  reroute  path  is  found.  It 
is  used  when  looking  up  path  assessment  time  (PAT)  in  the 
PAT  table. 

Path  assessment  time  is  looked  up.  PAT  is  a  function  of  both 
reroute  path  length  and  ACOC  effectiveness.  ACOC  effective¬ 
ness  was  computed  in  the  previous  procedure. 

PAT  TABLE _ 

7 5  — ACOC  effectiveness 

0  I 

1  i 

2  ! 

2  : 

3  i 
_ 3_j 

path  length 

The  ROUTE  MASTER  record  is  read  and  saved  for  each  route  on 
the  RPR.  All  that  is  needed  from  the  route  master  record  at 
this  point  is  the  working  time  logs,  the  hour  counters  and 
the  orderwire  connectivity  flag. 

Local  damage  assessment  time  is  logged  on  each  route.  Local 
damage  assessment  time  is  the  time  of  the  disruption  plus 
the  following  four  minutes. 

NOTE  ON  LOGGING:  The  attack  scenarios  can  span  a  period  of 
up  to  24  hours.  To  cover  the  full  twenty  four  hours  in  the 
working  time  log  would  require  1440  bytes  for  each  route.  In 
order  to  reduce  the  record  size  and  at  the  same  time 
accompxish  tne  task,  a  working  time  log  of  3  hours  and  an 


elapsed  hour  counter  are  used.  Each  minute  in  the  working 
time  log  requires  one  byte.  When  the  3  hours  in  the  working 
time  log  have  been  filled,  all  the  entries  are  shifted  60 
minutes  to  the  left  and  the  elapsed  hour  counter  is  incre¬ 
mented  by  one.  Therefore,  before  any  times  are  logged,  it 
is  necessary  to  check  which  3  hour  slot  (out  of  24  hours) 
is  occupied  by  the  working  time  log. 

The  initiating  TCF  is  identified.  Reroute  action  for  a 
circuit  or  group  of  circuits  over  a  particular  path  is 
normally  initiated  by  one  or  the  other  tech  controllers 
at  the  end  points  of  the  reroute  path.  It  is  assumed  that 
either  could  initiate  the  reroute,  and  that  the  one  who  can 
do  it  first  will.  Therefore,  to  detemine  which  tech 
controller  gets  logged  with  path  assessment  time  it  is 
necessary  to  look  at  the  working  time  logs  for  the  two  end 
terminal  TCF's  and  see  which  one  has  the  first  idle  period 
equal  tc  the  path  assessment  time.  This  is  done  by  beginning 
at  the  next  minute  following  the  local  damage  assessment  time 
and  counting  idle  minutes  (blanks  or  zeroes)  until  the  number 
equals  the  path  assessment  time  and  noting  the  time  which 
this  occurs,  rr\e  tech  control  v;ith  the  earliest  such  time 
will  be  the  initiating  TCF. 

Path  assessment  time  is  logged  to  the  initiating  tech  control. 
NOTE:  It  should  be  pointed  out  at  this  time  that  working  time 
logs  for  end  terminals  TCF's  can  be  either  the  first  or  second 
one  in  a  route  master  record  depending  on  the  direction  of 
the  reroute  path,  or  the  sequence  in  which  the  routes  were 
found.  The  following  is  an  example  of  various  possibilities. 

LKF  DON  MRE  CLO 

• - • - • - • 

Reroute  path  =  DONLKFOl ,  CLOMREOl 
=  CLOMREOl,  DONMREOl 
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Route 

CLOMREOl 

DONMREOl 

DONLKFOl 

WTL '  s 

DON 

CLO 

Wire 

CLO 

(SD 

Route 

DONLKFOl 

DONMREOl 

CLOMREOl 

WTL's 

— £§§) 

DON 

CLO 

<£lcD 

MRE 

The  end  terminal  working  time  logs  (WTL)  were  circled  in 
each  case.  As  one  may  observe,  there  is  no  consistency  in 
where  the  e:.l  terminal  working  time  logs  will  be  located. 

However,  the  end  terminals  of  the  reroute  paths  are  listed  in 
the  RPR  and  they  can  be  used  to  locate  the  end  terminal 
working  time  logs. 

The  reroute  start  time  is  logged  in  the  RPR.  The  reroute 
start  time  is  the  first  minute  of  the  path  assessment  time. 

This  time  is  entered  in  the  space  reserved  for  it  in  the  RPR. 

CTl- — 2,CT2—  4 

CTl  and  CT2  are  coordination  and  patching  times.  For  the  first 
circuit  on  an  RPR,  2  and  4  minutes  are  used.  For  subsequent 
reroutes  on  the  same  RPR,  1  and  2  minutes  are  used.  CTl  is 
coordination  time  used  when  orderwire  connectivity  exists  between 
the  TCP's  at  two  ends  of  a  route.  CT2  is  the  time  used  when 
orderwire  connectivity  does  not  exist. 

The  orderwire  connectivity  flag  is  examined  to  determine  if 
orderwire  connectivity  exists  for  the  route.  A  "1"  indicates 
no  connectivity  and  a  "0"  indicates  connectivity. 

&  @  If  orderwires  exist,  CTl  minutes  is  logged  on  that  route. 

If  orderwires  do  not  exist,  CT2  minutes  is  logged.  When  logging 
CT,  logging  begins  at  the  initiating  tech  control  route  and 
works  towards  the  other  end.  The  fact  that  the  tech  controller 
at  both  ends  of  a  route  work  together  in  patching  up  the 
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circuit  is  accounted  for  when  logging  CT.  If  one  tech 
controller  is  busy  working  on  another  task,  the  other  tech 
controller  must  wait.  Therefore,  it  is  necessary  to  check 
both  working  time  logs  to  find  the  next  available  CT 
minutes  in  which  both  are  idle  (blanks  or  zeroes)  and  CT 
minutes  is  logged  to  both  tech  controls  (both  working  time 
logs)  . 


&  (cT)  If  CT  has  been  loqqed  on  all  the  routes  of  the  reroute 
then  restoral  time  is  entered  for  that  circuit  in  the  RPR. 
The  restoral  time  is  the  time  that  the  final  minute  was 
logged  on  the  final  route. 


p^th 


(?)  &  (5)  If  all  the  circuits  on  the  RPR  have  been  loaqed  then  the  RPP 
is  returned  to  the  RPR  file  after  setting  the  status  to  1 . 

Status  one  at  this  point  simply  indicates  that  the  RPR  has  been 
logged. 


©  &  ©)  If  restoral  times  have  been  computed  on  all  the  RPR's  then 
.the  RPR  file  is  returned  to  disc. 

©  If  all  theaters  have  been  completed,  then  control  is  returned 
to  the  calling  program. 


2.20  Subroutine  6.0  -  Update  CCSD  Records 


Referring  to  Figure  2-20,  this  procedure  updates  the  CCSD  master 
records  to  reflect  circuit  restoral  time  and  change  in  connectivity 
due  to  the  reroute  path. 


A  theater  RPR  file  is  read. 


An  RPR  from  the  file  is  read 


If  the  RPR  status  is  equal  to  9,  then  a  reroute  path  was 
found. 


A  CCSD  is  read  from  the  RPR. 


The  CCSD  Master  Record  is  read. 
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Figure  2-20.  Subroutine  6.0  Update  CCSD  Records  (sheet  1  of  3) 


Figure  2-20.  Subroutine  6.0  -  Update  CCSD  Records  (sheet  2  of  3) 
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(f)  If  the  multipoint  flag  is  not  equal  to  zero,  then  the  circuit 
is  multipoint  and  a  separate  procedure  is  used. 

(g)  If  the  in  time  in  the  CCSD  master  record  is  equal  to 
then  another  disruption  exists  on  the  circuit  for  which  no 
reroute  path  could  be  found.  Therefore,  the  circuit  cannot 
be  logged  in. 

The  CCSD  Master  in  time  is  compared  with  the  RPR  in  time. 

If  the  RPR  in  time  is  not  greater  than  the  CCSD  in  time, 
then  the  in  time  which  is  currently  entered  in  the  CCSD 
Master  is  used.  This  situation  occurs  when  a  circuit  is 
disrupted  at  two  separate  locations.  The  latest  in  time  is 
used,  since  the  circuit  will  not  be  restored  until  all  reroutes 
are  up. 

If  RPR  in  time  is  greater,  then  it  is  entered  into  the  CCSD 
master. 

Also  the  CCSD  status  is  set  to  0,  operational. 

If  it's  a  VFCT,  (m)  the  teletype  circuits  riding  it  must  be 
logged  in. 

If  all  CCSD's  have  been  read,  the  procedure  is  repeated  for 
the  next  RPR. 

If  all  RPR* s  have  been  read,  (q)  the  RPR  file  is  erased  and 
the  procedure  is  repeated  for  the  next  theater. 

After  all  the  theaters  are  finished,  all  the  asterisk  (*'s) 
from  the  CCSD  m  times  that  were  inserted  earlier  must  be 
removed.  They  are  not  wanted  during  the  next  pass  through 
the  restoral  algorithm. 

The  theater  disrupted  circuits  list  is  read. 

A  CCSD  is  read  and  (u)  the  CCSD  Master  is  read  and  the  in 
time  set  to  9999. 
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(v)  &  ('w'  After  all  CCSD's  in  all  theaters  have  been  read,  control 
is  returned  to  the  calling  program. 

©  If  the  status  is  not  9,  a  CCSD  is  read,  ©>  the  CCSD  master 
is  found  and  (z)  the  CCSD  Master  status  set  to  the  value  of 
RPR  status. 

2.21  Subroutine  6.1  -  Log  Multipoint  Segments 

Referring  to  Figure  2-21,  this  procedure  is  used  to  log  in  the 

segments  of  a  multipoint  circuit. 

A  segment  CCSD  Master  record  is  read. 

If  the  segment  status  is  not  1  or  0,  then  there  is  a  reason 
why  the  circuit  cannot  be  restored  and  it  is  not  logged  in. 

The  status  may  be  0,  operational,  because  it  may  have  already 
been  restored  at  another  break  in  this  segment  and  the  status 
changed  from  1  to  0. 

©5  Segment  CCSD  connectivity  is  examined  to  see  if  it's  an 

affected  segment.  Some  segments  may  be  affected  by  a  dis¬ 
ruption,  while  other  segments  are  not.  It  must  be  deter¬ 
mined  if  this  segment  is  affected  by  this  particular 
disruption. 

(©  The  symbol  "*"  is  used  to  indicate  that  a  reroute  was  attempt¬ 
ed  on  this  disruption  but  the  reroute  path  was  disrupted 
again  before  it  could  be  completed.  Therefore,  if  there  are 
other  reroutes  on  this  segment,  the  circuit  is  not  logged  in. 

©)  Is  segment  in  time  =  9999.  If  it  is,  the  program  proceeds 

to  (©  and  enters  RPR  in  time  in  the  segment  CCSD  master  record. 

(f)  The  segment  CCSD  in  time  is  compared  to  the  RPR  in  time. 

(g)  &  ©)  If  the  RPR  in  time  is  greucer  than  the  CCSD  m  time  then  the 

RPR  in  time  becomes  the  new  CCSD  in  time,  since  the  segment 
is  not  restored  until  all  reroutes  are  up  and  the  restoral 
time  will  be  the  time  that  the  last  reroute  was  put  up. 


Figure  2-21.  Subroutine  6.1-  Log  Multipoint  Segments  In 
(sheet  1  of  2) 


Figure  2  21.  Subroutine  6.1  -  Log  Multipoint  Segments 
(sheet  2  ot  2) 


Tne  segment  CCSD  status  is  set  to  0. 

(?)  If  all  the  segments  have  been  checked,  the  parent  CCSD  Master 
is  updated. 

(k)  through  (o)  Same  as  above. 


SECTION  3  -  CRAM  DATA  BASE 

This  section  contains  a  description  of  the  CRAM  data  base 
schema  and  content  and  a  description  of  the  data  base  build 
process. 

3.1  Data  Base  Schema 

Figure  3-1  is  a  schematic  representation  of  the  CRAM  data  base 
utilizing  the  TOTAL  Data  Base  Management  System.  The  CRAM  data 
base  is  divided  into  two  sections,  the  connectivity  section  and 
the  restoral  section.  The  connectivity  section  contains  all 
static  DCS  connectivity  related  information;  whereas  the  restoral 
section  contains  working  files,  the  contents  of  which  will  be 
manipulated  during  the  execution  of  the  algorithm.  The  following 
is  a  list  of  files  together  with  a  brief  discussion  of  the  use 
of  each  file.  A  table  is  also  provided  for  each  file  which  details 
the  data  sets  and  the  file  structure. 

AALM  -  ACOC  Access  Line  Master  File 

The  ACOC  Access  Line  Master  File  contains  descriptive 
information  about  each  circuit  as  well  as  a  path  to  the  ACOC 
Access  Line  Variable  file.  By  interaction  with  this  file, 
the  theater  and  reporting  station  to  which  the  circuit  is 
connected  can  be  obtained.  AALM  data  sets  and  file  structure 
are  detailed  in  Table  3-1. 

ATCM  -  ACOC  Theater  Connectivicy  Master  File 

The  ACOC  Theater  Connectivity  Master  File  contains  the  list 
of  all  the  reporting  stations  in  the  DCS.  The  ACOC  Theater 
Connectivity  Master  file  interacts  with  the  ACOC  Access  Line 
Variable  file  to  obtain  all  the  access  lines  to  the  reporting 
station.  ATCM  data  sets  and  file  structure  are  detailed  in 
Table  3-2. 
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CXTM  ~  Circuit  Master  File 


The  Circuit  Master  File  contains  descriptive  information 
about  each  circuit  as  well  as  a  path  to  the  Circuit  List  (CKLV) 
and  the  Circuit  Routing  (CKRV)  variable  files.  By  interaction 
with  these  two  files,  the  network,  path  and  trunks  related 
to  a  given  circuit  can  be  found.  CKTM  data  sets  and  file 
structure  are  detailed  in  Table  3-3. 

CSTM  -  Change  of  Status  Master 

The  Change  of  Status  Master  File  will  contain  the  CCSF 
numbers  for  circuits  that  have  changed  status  during  the 
scenario.  This  file  will  also  contain  the  list  of  trunk/ 
channels  that  change  status  because  of  preemption  duri:.g  the 
scenario.  CSTM  data  sets  and  file  structure  are  detailed  in 
Table  3-4. 

DCKM  -  Disrupted  Circuits  Master  File 

The  Disrupted  Circuits  Master  File  contains  the  records  of 
the  CCSDs  that  have  been  disrupted  by  the  scenario.  The 
Disrupted  Circuits  Master  File  is  directly  linked  to  the 
Disrupted  Circuits  Variable  file.  Interaction  with  the  file 
will  tell  the  user  where  the  endpoints  of  a  disruption (s)  is. 
DCKM  data  sets  and  file  structure  are  detailed  in  Table  3.5, 

LNKM  -  Link  Master  File 

The  Link  Master  File  contains  information  describing  a 
link  between  two  stations.  The  Link  Master  File  is  associated 
with  two  variable  files,  the  Trunk  Routing  (TRRV)  and  the  Link 
(LNKV)  variable  files. 

The  Link  Master  File  supplies  descriptive  information  about 
the  links  listed  in  the  TRRV  and  the  LNKV  files.  LNKM  data 
sets  and  file  structure  are  detailed  in  Table  3-6. 


Table  3-3.  CKTM-Circuit  Master  File  (sheet 
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Table  3-4.  CSTM-Change  of  Status  Master  File  (Sheet 
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Table  3-6.  LNKM-Link  Master  Pile 


NETM  -  Network  Master  File 


The  Network  Master  File  contains  the  identifications  of 
various  networks  and  pointers  to  the  circuit  list  variable 
file  (CKCV) .  Its  main  use  is  to  supply  information  about 
the  specified  networks  and  through  the  CKCV  file  to  list  all 
circuits  in  a  particular  network.  NETM  data  sets  and  file 
structure  are  detailed  in  Table  3-7. 

PTHM  -  Path  Master  File 

The  path  concept  allows  circuits  that  are  routed  over  the 
same  geophysical  locations  to  be  grouped  together  for  easier 
handling  by  various  report  programs.  The  PTHM  file  contains 
the  path  identification  and  pointers  to  the  circuit  list 
variable  file  (CKLV) .  Access  to  the  CKLV  file  will  supply 
all  circuits  on  the  path.  Any  given  circuit  within  a  path 
will  supply  the  routing  of  the  path.  PTHM  data  sets  and  file 
structures  are  detailed  in  Table  3-8. 

RPAM  -  Restoral  Path  Master  File 

The  Restored  Path  Master  File  contains  information  des¬ 
cribing  the  path  of  routes  that  have  been  made  to  bridge 
a  disruption  of  another  route  in  the  system.  The  CCSDs 
restored  over  the  reroute  path  are  found  by  interacting 
with  the  Restored  Path  Variable  File.  RPAM  data  sets  and 
file  structure  are  detailed  in  Table  3.9 

RRPM  -  Reroute  Path  Master  File 

The  Reroute  Path  Master  File  contains  the  list  of  disrupted 
endpoints  for  which  a  reroute  is  available.  The  Reroute  Path 
Master  File  interacts  with  the  Reroute  Path  Variable  File  to 
obtain  all  the  disrupted  circuits  between  the  two  endpoints 
that  can  be  rerouted.  RRPM  data  sets  and  file  structure  are 
detailed  in  Table  3-10. 
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Table  3-7.  NETM-Network  Master  File 
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Table  3-9.  RP AM-Restored  Path  Master  File 
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ri;qu  l red  to  bridge  the  break  between  the  two  end 
points.  If  a  lx  routes  are  needed  the  field  is  blank 


RTEM  -  Route  Master  File 

A  route  is  a  group  of  trunks  that  traverse  the  same 
geophysical  locations.  The  Route  Master  File  contains  the 
identifications  and  other  descriptive  information  pertaining 
to  all  identified  routes.  The  Route  Master  File  interacts 
with  the  Trunk  List  (TRLV)  Variable  file.  Access  to  this 
file  will  supply  all  trunks  for  a  given  route.  RTEM  data 
sets  and  file  structure  are  detailed  in  Table  3-11. 

STNM  -  Station  Master  File 

The  Station  Master  File  contains  records  that  describe  the 
physical  locations  of  stations  within  the  DCS.  The  Station 
Master  File  interacts  with  two  variable  files.  Trunk  Routing, 
and  Link.  Interaction  with  the  Trunk  Routing  File  will  supply 
information  about  the  various  trunks  that  traverse  a  given 
station.  All  links  at  a  given  station  are  supplied  by  accessing 
the  Link  Variable  File.  STNM  data  sets  and  file  structures 
are  detailed  in  Table  3-12. 

THRM  -  Theater  Master  File 

The  Theater  Master  File  contains  records  that  describe  the 
designated  ACOC  within  each  theater  or,  as  is  the  case  of  the 
Pacific,  the  RCOCs  within  each  region.  The  Theater  Master 
File  interacts  with  the  ACOC  Access  Line  file  so  that  all 
lines  connected  to  the  ACOC  can  be  accessed  via  this  linkage 
path.  THRM  data  sets  and  file  structure  are  detailed  in 
Table  3-13. 

TRCM  -  Theater  Routes  Connectivity  Master  File 

The  Theater  Route  Connectivity  Master  file  contains  records 
that  describe  the  route  connectivity  of  stations  in  the  DCS. 

A  route  is  a  group  of  trunks  that  traverse  and  terminate  the 
same  geographical  locations.  The  Theater  Route  Connectivity 
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Key  Element 


Table  3-11.  RTEM- Route  Master  File  (sheet  2  of  2) 


File 


Master  file  contains  a  list  of  stations  and  associated  routes. 
If  there  are  more  routes  connected  to  the  station  than  allowed 
for  in  the  Theater  Route  Connectivity  Master  File,  then  the 
excess  is  contained  in  the  Theater  Route  Connectivity  Variable 
file.  TRCM  data  sets  and  file  structure  are  detailed  in 
Table  3-14. 

TRKM  -  Trunk  Master  Files 

The  Trunk  Master  File  contains  descriptive  information 
pertaining  to  the  trunks  in  the  Circuit  Routing  (CKRV) , 

Trunk  List  (TRLV)  and  Trunk  Routing  (TRRV)  variable  files. 
Interaction  with  the  TRRV  file  will  supply  information  about 
the  various  stations  and  links  that  the  trunk  traverses  while 
interaction  with  the  TRLV  file  will  supply  the  route  for  a 
given  circuit.  All  circuits  on  the  trunk  can  be  obtained 
through  accesses  of  the  CKRV  Variable  File.  TRKM  data 
sets  and  file  structure  are  detailed  in  Table  3-15. 

WSLM  -  Working  Station  Master  File 

The  Working  Station  Master  contains  information  describing 
the  working  status  of  stations  involved  in  rerouting  circuits: 
WSLM  data  sets  and  file  structure  are  detailed  in  Table  3-16. 

WTLH  -  Working  Time  Log  Master  File 

The  Working  Time  Log  Master  File  contains  the  log  of  a 
Tech  controllers  reroute  activity  time  in  each  facility.  The 
tech  controllers  activity  is  logged  by  route.  WTLM  data  sets 
and  file  structure  are  detailed  in  Table  3-17. 

AALV  -  ACOC  Access  Line  Variable  File 

The  ACOC  Access  Line  Variable  File  provides  easy  access 
to  all  the  technical  control  facility  to  ACOC  communications 
lines  in  the  DCS.  This  file  contains  descriptive  information 
about  each  circuit  as  well  as  linkage  paths  to  the  ACOC  access 
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Table  3-14.  TRCM-Theater  Route  Connectivity  Master  File 


able  3-17.  WTLM-Working  Time  Log  Master 
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*Key  Element 


and  the 


Line  Master  File,  the  ACOC  Theater  Master  File, 

Theater  Master  File.  Interaction  with  these  files  provides 
information  about  the  technical  control  reporting  station 
circuits  within  the  theater.  AALV  data  sets  and  file 
structures  are  detailed  in  Table  3-18. 

CKLV  -  Circuit  Listing  Variable  File 

The  Circuit  Listing  Variable  File  (CKLV)  provides  an  easy 
access  to  all  circuits  on  a  given  path.  It  also  allows  all 
circuits  within  a  particular  network  to  be  readily  identified. 
Detailed  information  concerning  paths,  circuits  and  networks 
can  be  obtained  through  the  Path,  Circuit  and  Network  Master 
files  respectively.  CKLV  data  sets  and  file  structure  are 
detailed  in  Table  3-19. 

CKRV  -  Circuit  Routing  Variable  File 

The  Circuit  Routing  Variable  File  (CKRV)  contains  the 
routing  of  the  DCS  circuits  in  terms  of  the  trunks  and  the 
channels  they  traverse.  Detailed  information  concerning 
a  given  circuit  is  found  by  accessing  the  circuit  master 
file  (CRTM) .  Accessing  the  Trunk  Master  File  (TRKM)  will 
provide  detailed  information  about  the  trunks  listed  in  the 
CKRV  file.  CKRV  data  sets  and  file  structure  are  detailed  in 
Table  3-20. 

CSTV  -  Change  of  Status  Variable  File 

The  Change  of  Status  Variable  File  is  used  to  store  CCSD 
and  trunk/channel  information  for  reroute  paths.  The  Change 
of  Status  Variable  File  is  linked  to  the  Change  cf  Status 
Master  File.  By  interaction  with  these  two  files  information 
about  a  CCSD  status  can  be  obtained.  CSTV  data  sets  and  file 
structure  are  detailed  in  Table  3-21. 


Table  3-18.  AALV-ACOC  Access  Line  Variable  File 


IP* . . 


Table  3-20.  CKRV-Circuit  Routing  Variable  File 


DCKV  -  Disrupted  Circuit  Variable  File 


The  Disrupted  Circuits  Variable  File  contains  information 
about  disruptions  (the  endpoints  involved)  for  each  circuit 
disrupted  in  the  scenario.  The  data  from  this  file  is  used 
in  creating  Reroute  Path  Master  and  Reroute  Path  Variable 
Files.  DCKV  data  sets  and  file  structure  are  detailed  in 
Table  3-22. 

LNKV  -  Link  Variable  File 

The  Link  Variable  File  provides  an  easy  access  to  all 
links  at  a  given  site.  Both  ends  of  a  link  are  listed  with 
the  link  ID  and  so  only  one  record  entry  per  link  is  required 
Detailed  link  information  can  be  accessed  through  the  Link 
Master  file  (LNKM) .  Detailed  station  information  can  be 
accessed  through  the  Station  Master  File  (STNM) .  LNKV  data 
sets  and  file  structure  are  detailed  in  Table  3-23. 

RPftV  -  Restoral  Path  Variable  File 

The  Restored  Path  Variable  File  contains  descriptive 
material  about  the  CCSDs  restored  on  a  particular  reroute 
path.  RPAV  data  sets  and  file  structure  are  detailed  in 
Table  3-24. 

RRPV  -  Reroute  Path  Variable  File 

The  Reroute  Path  Variable  File  contains  the  list  of  CCSDs 
to  be  rerouted  between  two  points  plus  some  descriptive 
information  about  each.  The  Reroute  Path  Variable  File  is 
linked  to  the  Reroute  Path  Master  File  which  contains  the 
information  about  the  reroute.  RRPV  data  sets  and  file 
structure  are  detailed  in  Table  3-25. 

TRCV  -  Theater  Route  Connectivity  File 

The  Theater  Route  Connectivity  Vairable  File  contains  a 
list  of  stations  and  associated  routes  which  represent  the 


Table  3-22.  DCKV-Disrupted  Circuit  Variable  File 


"  . . . . . . . . . 


physical  connectivity  of  stations.  This  file  is  linked  to 
the  Theater  Route  Connectivity  Master  File  which  also  contains 
the  same  data  but  for  a  different  set  of  stations.  The 
Theater  Route  Connectivity  Variable  File  is  used  only  when  a 
particular  station  is  connected  by  more  than  5  different  routes. 
TRCV  data  sets  and  file  structure  are  detailed  in  Table  3-26. 

TRLV  -  Trunk  Listing  Variable  File 

The  Trunk  List  Variable  File  (TRLV)  provides  an  access 
to  all  trunks  on  a  given  route.  Detailed  route  information 
can  be  accessed  through  the  Route  Master  File  (RTEM) .  Detailed 
trunk  information  can  be  accessed  through  the  Trunk  Master 
File  (TRKM) .  TRLV  data  sets  and  file  structure  are  detailed 
in  Table  3-27. 

TRRV  -  Trunk  Routing  Variable  File 

The  Trunk  Routing  Variable  File  provides  the  routing  of 
the  DCS  trunks  in  terms  of  the  stations  and  links  the  trunks 
traverse.  Detailed  information  about  the  stations  and  links 
is  provided  in  the  Station  Master  File  (STEM)  and  Link  Master 
File  (LNKM)  respectively.  TRRV  data  sets  and  file  structure 
are  detailed  in  Trble  3-28, 

3.2  Data  Base  Sizing 

The  total  size  of  the  CRAM  data  base  is  50.1  megabytes. 

Tables  3-29  and  3-30  provide  record  sizes,  file  capacities  and  total 
file  sizes  for  the  connectivity  and  restoral  sections  of  the 
data  base,  respectively. 

3.3  Data  Base  Build  Process 

The  primary  source  of  data  used  in  building  the  CRAM  data 
base  was  the  DCA  World  Wide  On  Line  System  (WWOLS).  CSC  was 
supplied  with  tape  extracts  from  the  WWOLS  which  contained  the 
complete  circuit  and  trunk  lists  for  the  European  DCS.  Other 
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Table  3-26  TRCV-Theater  Route  Connectivity  File 


Table  3-28  TRRV-Trunk  Routing  Variable  File 


Table  3-29.  Connectivity  Data  Base  Sizing 


data  sources  included  DCA  circulars  and  CSC  generated  data. 

The  restoral  section  of  the  data  base  does  not  require  any 
data  entry  prior  to  the  execution  of  the  CRAM  algorithm,  but 
contains  working  files  used  for  temporary  storage  and  manipulation 
of  data  during  program  execution.  The  connectivity  section  of 
the  data  base  contains  the  DCS  connectivity  and  other  static 
data  required  by  the  CRAM.  Information  in  the  connectivity 
section  of  the  data  base  must  be  loaded  prior  to  execution  of 
the  algorithm.  Figure  3-2,  and  the  following  discussion  detail 
the  connectivity  data  base  load  process. 

(a)  Convert  the  circuit  tapes  to  ASCII  format.  The  output  file 
may  be  on  disk  or  tape  or  both. 

(b)  Sample  the  converted  files  in  order  to  determine,  in  general, 
the  contents  and  format. 

(3)  Create  the  circuit  master  and  circuit  routing  variable 

records  which  are  loaded  into  the  data  base.  In  the  process 
of  reading  the  circuit  connectivities,  link  and  trunk  names 
must  be  assigned  where  names  are  not  assigned  by  DCA.  A 
direct  file  with  these  dummy  keys  is  kept.  The  stations  that 
these  dummy  links  connect  is  also  used  tc  *orm  station  master 
records  since  there  is  no  guarantee  that  these  stations  will 
appear  on  the  trunk  tape.  Pre-planned  alt-route,  multipoint 
and  undirectional  circuits  are  handled  in  this  module. 

(B)  Convert  the  trunk  tape  to  ASCII  format.  The  output  file  may 
be  on  disk  or  tape  or  both. 

(3)  Sample  the  converted  files  in  order  to  determine  in  general 
the  contents  and  format. 

(f)  Create  trunk  master  and  trunk  routing  variable  records  which 
are  to  be  loaded  into  the  data  base.  In  the  process  of  read¬ 
ing  the  trunk  connectivities,  station  master  records,  link  master 
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Figure  3-2.  Data  Base  Build  Process  (sheet  1  of  5) 


PROCESS  I S’C 


N\ 


3-2.  Data 


Base  Build  Process  (sheet  2  of  5) 


jll'li'llft,  <,*, 


INPUT 


PROCESSING 


records  and  link  variable  records  are  formed.  Some  of 
the  link  records  are  for  CSC  assigned  link  identifiers. 

These  links  are  added  to  the  file  of  CSC  assigned  trunks  and 
links  created  in  step  {CJ  .  A  trunk  master  record  will  be 
created  for  each  trunk.  However.,  no  routing  records  will  be 
created  for  VFCT  trunks. 

Use  a  SORT  utility  to  sort  the  station  master  records  created 
in  step  (f)  and  print  the  sorted  file.  This  file  is  used  as 
a  list  of  all  the  stations  for  which  information  must  be 
gathered. 

Use  a  SORT  utility  to  sort  the  link  master  records  created 
in  step  (f)  ,  printing  the  resulting  sorted  file.  This 
file  is  used  as  a  list  of  all  the  links  for  which  information 
must  be  gathered. 

Create  the  DBMOD  file  (Data  Base  Descriptor  Table)  by  running 
the  DBGEN  program  with  the  CRAM  data  base  schema  as  input. 

Load  the  station  master  data  set  using  the  station  file 
generated  in  step  (g)  .  This  file  includes  all  station 
names.  Other  station  data  is  not  included  at  this  time. 

Load  the  link  master  data  set  using  the  link  file  generated 
in  step  ©  .  This  file  will  include  DCS  links  and  dummy 
links  assigned. 

Load  the  trunk  master  data  set  using  the  trunk  file  generated 
in  step(F)  .  This  file  includes  all  DCS  trunks  and  dummy 
trunks  assigned. 

Load  the  circuit  master  data  set  using  the  circuit  file 
generated  in  step  (cj  .  This  file  includes  all  DCS  circuits 
including  unidirectional,  multipoint  and  pre-planned 
alt- route  circuits. 

Load  the  link  variable  data  set  using  the  link  file  generated 
in  step  ©  .  This  file  includes  all  DCS  links  and  dummy 
links  assigned. 
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Load  the  trunk  routing  variable  data  set  using  the  trunk 
file  generated  in  step  (f)  .  This  file  includes  DCS  trunks 
and  dummy  trunks  assigned  but  does  include  VFCT  trunk 
routing. 

This  step  involves  the  loading  of  the  circuit  routing 
variable  data  set  using  the  circuit  file  generated  in 
step  (£)  .  This  file  will  include  all  circuits  including 

unidirectional,  multipoint  and  pre-planned  alt-route 
circuits. 

Collect  missing  station  information  for  those  stations 
loaded  into  the  data  base.  These  stations  will  be  found  in 
the  printout  of  the  station  master  load  file  generated  in 
step  (cT)  .  The  missing  information  includes  latitude, 
longitude,  three  letter  site  code,  station  description 
code  and  plotter  number.  The  source  of  this  data  is  DCS 
circular  and  CSC  documentation. 

Collect  missing  link  information  for  those  links  loaded  into 
the  data  base.  These  links  are  found  in  the  printout  of 
the  link  master  load  file  generated  in  step  (^T)  .  The 
missing  information  includes  the  plotter  number  for  each 
link. 

Update  the  station  master  records  with  the  information 
gathered  in  step  (q)  .  The  information  source  is  punched 
cards. 

Update  the  link  master  records  with  the  information  gather¬ 
ed  in  step  (r)  .  The  information  source  is  punched  cards. 

Load  the  VFCT  trunk  connectivity.  The  source  of  informa¬ 
tion  is  the  circuit  and  trunk  master  data  sets  and  trunk 
routing  variable  data  set  generated  in  steps  (m)  ,  (J)  , 
and  (p)  ,  respectively. 
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Load  the  network  master  data  set.  The  information  is  read 
from  a  disk  file  and  loaded  directly  into  the  data  base. 

The  number  of  records  to  be  loaded  is  less  than  twenty 
so  the  file  is  generated  manually. 

Load  the  connectivity  records  for  each  segment  of  the 
multipoint  circuits.  The  source  of  information  is  the 
extraction  of  the  DCS  circuits  tapes  ((T)  ,  and  the  trunk 
routing  and  circuit  master  records  generated  in  steps  (k) 
and  (o)  . 

Load  the  path  master  and  circuit  list  variable  data  sets. 
The  informatxon  source  is  the  circuit  master  file  generated 
in  step  ®  and  the  circuit  routing  and  trunk  routing 
variable  data  sets.  The  process  involves  sorting  these 
circuits  on  endpoints,  analyzing  the  connectivity  for 
those  with  the  same  endpoints  and  assigning  the  path  names 
accordingly. 

Load  the  theater  master  data  set  from  a  manually  cons¬ 
tructed  disk  file.  The  number  of  records  is  small  enough 
that  the  manual  build  of  the  disk  file  is  justifiable. 

Load  the  ACOC  theater  connectivity  master  with  all 
reporting  stations  in  the  DCS.  The  input  is  a  manually 
constructed  disk  file. 

Load  the  ACOC  access  line  master  and  variable  data  sets. 

The  input  will  come  from  the  data  base  records  already 
entered  including  the  theater,  ACOC  theater  connectivity 
and  circuit  master  as  well  as  routing  and  circuit  routing 
variable  files  generated  in  steps  (y),(z)  »  (o)  ,  (p)  , 
and  (m)  ,  respectively. 


Generate  the  route  master  file  and  trunk  list  variable 
fiie.  The  information  source  is  the  trunk  and  station 
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master  files  as  well  as  the  trunk  routing  file  generated 
in  steps  (l)  ,  (jj  ,  ana  (oj  ,  respectively.  All  input 
is  strictly  within  the  data  base. 


Load  the  theater  route  connectivity  master  and  variable 
data  set.  The  input  is  the  route  master  file  generated 

in  cfon 


SECTION  4  -  SAMPLE  OUTPUTS 


Figures  4-1  through  4-4  show  four  specific  types  of  outputs 
from  the  CRAM.  These  outputs  show  the  impact  of  losing  a 
major  node  (classified  name)  in  the  European  DCS. 

Figure  4-1  show:?  a  summary  of  all  reroute  actions  as  a 
result  of  the  damage  scenario.  It  identifies  the  total  number 
of  reroutes  attempted  and  the  number  completed.  The  summary 
of  completed  reroutes  is  grouped  according  to  reroute  path 
length  to  show  the  number  of  routes  required  in  tandem  to 
satisfy  the  reroute  requirements. 

Figure  4-2  shows  a  summary  of  the  effect  of  the  scenario 
on  ACOC  connectivity.  ACOC  connectivity  is  composed  of 
critical  control  communications  circuits  between  the  ACOC  and 
the  technical  control  facilities.  Based  upon  the  circuits 
surviving  the  damage  scenario,  an  estimate  of  ACOC  effective¬ 
ness  is  calculated.  This  quantity  is  then  used  as  a  weighting 
factor  in  calculating  the  response  times  for  circuit  restoral. 

Figure  4-3  lists  the  circuits  by  CCSD  which  were  preempted 
as  a  result  of  restoring  higher  priority  circuits. 

Figure  4-4  is  a  circuit  status  table  showing  the  status  of 
a]  i.  circuits  in  a  given  theater  of  operation  after  a  damage 
scenario  and  subsequent  restoral  actions  have  been  taken.  The 
status  of  all  or  selected  circuits  can  be  provided.  Circuits 
not  affected  by  the  scenario  are  also  listed.  Disrupted 
circuits  are  listed  together  with  restoral  times,  restoral 
actions,  and  remarks  to  indicate  why  unrestored  circuits  could 
not  be  restored.  This  table  is  useful  in  determining  the 
impact  of  damage  to  the  system  and  the  ability  of  the  system 
control  to  utilize  remaining  resources  to  restore  critical 
high  priority  circuits. 
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Figure  4-2.  ACOC  Connectivity  Summary 


•’-Lfcvfttx  C I^Cvl  T S 

rage  eul  of  0/1 

1*1*1  s  «*79 


f  j  s 

i  ? « 

_» 

Ct$«x 

CCSD 

RP 

CC3U 

HP 

-  -  * 

•  « 

-  •  -  - 

-  - 

mmmm 

•  • 

«••• 

mm 

•••• 

»• 

_•  lqcc: 

t.C  *~i  c 

a: 

07  1  «fc.F9tt 

10 

Jhjv-EnZ 

2F 

0UBB90F3 

00 

-w7»~©S? 

* 

o* 

J^I.USU 

a 

VC592 

2E 

RCIE9HBT 

IS 

•  ivc ;/ . 

1 

J  3.-*  - 

a* 

J0*v*tj JS 

?«* 

J*DV«SPX 

21 

UUBV»89l 

0P 

•  u?** 

2* 

•‘  C-fCv. 

i«‘. 

C»;uC9a03 

is 

UUBB9AS* 

00 

UKIE9CKR 

1G 

1 

». 

I"'  JS 

5* 

JOl.Ciao 

3A 

Jhjv^EF7 

21 

0UUC9A0B 

1C 

J  ■*  1  v  -  - 1  - 

at 

„•  -  c->cctf 

1’* 

CUUC9DS« 

3<J 

UU999CQK 

38 

UOBVC775 

00 

; 

i« 

■  c«cc- 

?e 

J^iv-EFZ 

2E 

0UUC9CCS 

u 

J-l»  •*•’. 

i* 

»,  c<».  -t 

DTPX6003 

**3 

uOBVDBJI 

30 

CUUC90JZ 

80 

at 

■  .  O  ,r 

T  * 

mji£»«»o 

IS 

UUBB5»Sx 

.*3 

UK1E9CNR 

ic 

*  >,t  Ui. 

/ 

C<JC«-v 

2- 

J0*V*AM 

3a 

0UUC9CJV 

30 

JUIVBEBT 

00 

'  C°CC* 

i- 

•  .Co* 

*£ 

0OUC910* 

IC 

0UUC9CCX 

00 

UU0B9CBJ 

00 

i) 

J-.v., 

JmOV*OLS 

ll 

JUJJC6E6 

2£ 

DUUC9CCN 

1C 

•*  »t  ►  '."f  , 

?i 

J-'l  i  'CSC 

21 

J0*v*»SF 

3A 

JU*V*09X 

30 

TWRVON50 

10 

0  ,t  C  9  *  >*> 

.*, 

»  -  C^CtZ 

»-.* 

JJG^*6Z 

2C 

00UC9CC* 

00 

JMIV.EE6 

00 

A  i 

»*/ 

-  .  Liz JS 

/ . 

Uo*et»9C  *Z 

0U1F9CJT 

IC 

B01B1E9J 

1C 

i* 

J  'i%  •• 

i 

l)oUC9*0T 

BE 

Figure  4-3.  Preempted  Circuit  Summary 
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Figure  4-4,  Circuit  Status  Summary  (sheet  5  of  5) 
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With  minor  modification,  the  CRAM  can  also  provide  reports 
which  show  the  actual  routing  of  rerouted  circuits. 
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